Davide Libenzi wrote: > On Tue, 16 Jun 2009, Gregory Haskins wrote: > > >> Does this all make sense? >> > > This conversation has been *really* long, and I haven't had time to look > at the patch yet. But looking at the amount of changes, and the amount of > even more changes talked in this thread, there's a very slim chance that > I'll ACK the eventfd code. > You may want to consider a solution that does not litter eventfd code that > much. > > > - Davide > > > Hi Davide, I understand your position and value your time/insight into looking at this things. Despite the current ongoing discussion, I still stand that the current patch is my proposed solution (though I have yet to convince Michael). But in any case, if you have the time, please look it over because I still think its the right direction to head in. The general solution is that we use an srcu list instead of the wait-queue, and thats really it. If we can't eliminate that spinlock held over the notification, it has usability implications at least for irqfd/iosignalfd. The only way I can think of to solve the problem without modifying eventfd is to not use eventfd at all. :( Since using eventfd really captures the concept we are going for here really well, reusing it has a ton of advantages including interface compatibility and, of course, code-reuse of a tested/debugged code base. Heck, we may hopefully even improve eventfd for other users in doing this work. It would therefore be a shame to walk away from it if it can be avoided. So if what I proposed is not acceptable but you are willing to work with me to find a solution that is, that would be ideal from my perspective. Otherwise, I apologize for all the noise. You have been quite the patient and helpful gentleman with me to date and I appreciate that. Kind Regards, -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
