On 2018-12-17 03:49, Roman Penyaev wrote:
On 2018-12-13 19:13, Davidlohr Bueso wrote:
Yes, good idea. But frankly I do not want to bloat epoll-wait.c with
my multi-writers-single-reader test case, because soon epoll-wait.c
will become unmaintainable with all possible loads and set of
different options.
Can we have a single, small and separate source for each epoll load?
Easy to fix, easy to maintain, debug/hack.
Yes completely agree; I was actually thinking along those lines.
I ran these patches on the 'wait' workload which is a epoll_wait(2)
stresser. On a 40-core IvyBridge it shows good performance
improvements for increasing number of file descriptors each of the 40
threads deals with:
64 fds: +20%
512 fds: +30%
1024 fds: +50%
(Yes these are pretty raw measurements ops/sec). Unlike your
benchmark, though, there is only single writer thread, and therefore
is less ideal to measure optimizations when IO becomes available.
Hence it would be nice to also have this.
That's weird. One writer thread does not content with anybody, only
with
consumers, so should not be any big difference.
Yeah so the irq optimization patch, which is known to boost numbers on
this microbench, plays an important factor. I just put them all together
when testing.
Thanks,
Davidlohr
