Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-23 Thread Eric Wong
Eric Wong wrote: > Arve Hjønnevåg wrote: > > > > At some point the level triggered event has to get cleared. As far as > > I can tell, your new code will drop new events that occur between > > "revents = ep_item_poll(epi, &pt);" and "epi->state = EP_STATE_IDLE;" > > in that case. > > Thanks for

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-22 Thread Eric Wong
Arve Hjønnevåg wrote: > On Fri, Mar 22, 2013 at 3:31 AM, Eric Wong wrote: > > Arve Hjønnevåg wrote: > >> On Thu, Mar 21, 2013 at 8:24 PM, Eric Wong wrote: > >> > > >> > With EPOLLET and improper usage (not hitting EAGAIN), the event now > >> > has a larger window to be lost (as mentioned in my

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-22 Thread Arve Hjønnevåg
On Fri, Mar 22, 2013 at 12:24 PM, Eric Wong wrote: ... > Perhaps just using epitem->ws and removing ep->ws can work. > > I think the following change to keep wakeup_source in sync with > epi->state is sufficient to prevent suspend. > > But I'm not familiar with suspend. Is it possible to suspend

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-22 Thread Arve Hjønnevåg
On Fri, Mar 22, 2013 at 3:31 AM, Eric Wong wrote: > Arve Hjønnevåg wrote: >> On Thu, Mar 21, 2013 at 8:24 PM, Eric Wong wrote: >> > >> > With EPOLLET and improper usage (not hitting EAGAIN), the event now >> > has a larger window to be lost (as mentioned in my changelog). >> > >> >> What about t

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-22 Thread Eric Wong
Eric Wong wrote: > Arve Hjønnevåg wrote: > > On Thu, Mar 21, 2013 at 8:24 PM, Eric Wong wrote: > > > > > > With EPOLLET and improper usage (not hitting EAGAIN), the event now > > > has a larger window to be lost (as mentioned in my changelog). > > > > > > > What about the case where EPOLLET is

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-22 Thread Eric Wong
Arve Hjønnevåg wrote: > On Thu, Mar 21, 2013 at 8:24 PM, Eric Wong wrote: > > > > With EPOLLET and improper usage (not hitting EAGAIN), the event now > > has a larger window to be lost (as mentioned in my changelog). > > > > What about the case where EPOLLET is not set? The old code did not > dr

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-21 Thread Arve Hjønnevåg
On Thu, Mar 21, 2013 at 8:24 PM, Eric Wong wrote: > Arve Hjønnevåg wrote: >> On Thu, Mar 21, 2013 at 4:52 AM, Eric Wong wrote: >> > Changes since v2: >> > * epi->state is no longer atomic, we only cmpxchg in ep_poll_callback >> > now and rely on implicit barriers in other places for reading. >

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-21 Thread Eric Wong
Arve Hjønnevåg wrote: > On Thu, Mar 21, 2013 at 4:52 AM, Eric Wong wrote: > > Changes since v2: > > * epi->state is no longer atomic, we only cmpxchg in ep_poll_callback > > now and rely on implicit barriers in other places for reading. > > * intermediate EP_STATE_DEQUEUE removed, this (with xc

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-21 Thread Arve Hjønnevåg
On Thu, Mar 21, 2013 at 4:52 AM, Eric Wong wrote: > This is still not a proper commit, I've lightly tested this. > > Replace the spinlock-protected linked list ready list with wfcqueue. > > This improves performance under heavy, multi-threaded workloads with > multiple threads calling epoll_wait.

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-21 Thread Eric Wong
Eric Wong wrote: > This is still not a proper commit, I've lightly tested this. Btw, full series here (already sent to LKML and some in -mm) http://yhbt.net/epoll-wfcqueue-v3.8.3-20130321.mbox (should apply cleanly to all 3.8/3.9 kernels) -- To unsubscribe from this list: send the line "unsubscri

[RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

2013-03-21 Thread Eric Wong
This is still not a proper commit, I've lightly tested this. Replace the spinlock-protected linked list ready list with wfcqueue. This improves performance under heavy, multi-threaded workloads with multiple threads calling epoll_wait. Using my multi-threaded EPOLLONESHOT microbenchmark, perform