On 03/05/2015 04:15 AM, Ingo Molnar wrote: > * Jason Baron <jbaron@xxxxxxxxxx> wrote: > >> 2) We are using the wakeup in this case to 'assign' work more >> permanently to the thread. That is, in the case of a listen socket >> we then add the connected socket to the woken up threads local set >> of epoll events. So the load persists past the wake up. And in this >> case, doing the round robin wakeups, simply allows us to access more >> cpu bandwidth. (I'm also looking into potentially using cpu affinity >> to do the wakeups as well as you suggested.) > So this is the part that I still don't understand. Here's maybe another way to frame this. Epoll sets add a waiter on the wait queue in a fixed order when epoll sets are added (via EPOLL_CTL_ADD). This order does not change modulo adds/dels which are usually not common. So if we don't want to wake all threads, when say an interrupt occurs at some random point, we can either: 1) Walk the list, wake up the first epoll set that has idle threads (queued via epoll_wait()) and return. or: 2) Walk the list and wake up the first epoll set that has idle threads, but then 'rotate' or move this epoll set to the tail of the queue before returning. So because the epoll sets are in a fixed order there is an extreme bias to pick the same epoll sets over and over regardless of the order in which threads return to wait via (epoll_wait()). So I think the rotate makes sense for the case where I am trying to assign work to threads that may persist past the wake up point, and for cases where the threads can finish all their work before returning back to epoll_wait(). Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
