> > Thanks to Andrew and John suggestions I coded another version of the
> > sys_epoll patch ( 0.13 skipped ... superstition :) ). I won't send the
> > patch to not waste bandwidth, the patch is available here :
> >
> > http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-last.diff
> >
> > Comments are welcome ...
>
>
> The previous and current versions of the sys_epoll patch are performing
> comparably and continue to far exceed the results from standard poll.
> Hopefully this is another endorsement for it's inclusion in the 2.5 kernel.
>
> We re-ran the SMP tests that were used to collect the sys_epoll performance
> data recently posted at http://lse.sourceforge.net/epoll/. Detailed data
> follows for those who want a closer look, or check out the website for
> more information.
Thank you very much Janet for doing performance and stability test.
Working with Andrew we agreed to remove the main hash table since, by
using in full the fcblist.c capabilities, it is not needed any more. Hash
allocation was a big Andrew concern because of its dimension and because
it was allocated with vmalloc() that might fail when fragmentation
increase. The new patch will have a reviewed locking behavior and will
introduce a slab allocator inside fs/fcblist.c. My plan is to release 0.16
today so that you guys can run regression test on it. To test the locking
"goodness" it should be run on an SMP system, with multiple copies of
ephttpd running on different ports, each one stressed either by httperf
or the sys_epoll HTTP blaster. Also, building an threaded application that
makes "bad use" of the interface might help in checking the API robustness
against every condition. Also, the usual performance test should be run to
check if we loose something along the path ...
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/