On 2018-12-06 00:46, Eric Wong wrote:
Roman Penyaev <rpenyaev@xxxxxxx> wrote:
Hi all,
The goal of this patch is to reduce contention of ep_poll_callback()
which
can be called concurrently from different CPUs in case of high events
rates and many fds per epoll. Problem can be very well reproduced by
generating events (write to pipe or eventfd) from many threads, while
consumer thread does polling. In other words this patch increases the
bandwidth of events which can be delivered from sources to the poller
by
adding poll items in a lockless way to the list.
Hi Roman,
I also tried to solve this problem many years ago with help of
the well-tested-in-userspace wfcqueue from Mathieu's URCU.
I was also looking to solve contention with parallel epoll_wait
callers with this. AFAIK, it worked well; but needed the
userspace tests from wfcqueue ported over to the kernel and more
review.
I didn't have enough computing power to show the real-world
benefits or funding to continue:
https://lore.kernel.org/lkml/?q=wfcqueue+d:..20130501
Hi Eric,
Nice work. That was a huge change by itself and by dependency
on wfcqueue. I could not find any valuable discussion on this,
what was the reaction of the community?
It might not be too much trouble for you to brush up the wait-free
patches and test them against the rwlock implementation.
Ha :) I may try to cherry-pick these patches, let's see how many
conflicts I have to resolve, eventpoll.c has been changed a lot
since that (6 years passed, right?)
But reading your work description I can assume that epoll_wait() calls
should be faster, because they do not content with ep_poll_callback(),
and I did not try to solve this, only contention between producers,
which make my change tiny.
I also found your https://yhbt.net/eponeshotmt.c , where you count
number of bare epoll_wait() calls, which IMO is not correct, because
we need to count how many events are delivered, but not how fast
you've returned from epoll_wait(). But as I said no doubts that
getting rid of contention between consumer and producers will show
even better results.
--
Roman
