On Tue, Jan 06, 2015 at 05:28:44AM -0800, Kent Overstreet wrote: > On Tue, Jan 06, 2015 at 02:03:17PM +0100, Peter Zijlstra wrote: > > Yeah I got that aspect. I'm still trying to get my head around how the > > wait_event bit would be a natural match though ;-) > > > > Let me stew a bit on that. > > Also, I think it was kind of a surprise to me back in the day how structurally > similar the wait_event() implementation (circa several years ago, not the > monstrosity it is now :) and closure_wait_event() turned out - I wasn't aiming > for that, but that got me thinking there must be something more fundamental > going on here.
That 'monstrosity' helped reduce the line count significantly, but more importantly it fixed a fair few inconsistencies across the various wait_event*() functions. But yes, its a bit of a handful. Now back to why I don't really like closures for this purpose; the wait_event*() stuff is really only a wait list, closures are a wait list + bits. So while it makes sense to me to implement closures in terms of wait_event, the reverse does not make sense to me. Now you gave a good reason to not use the existing wait list stuff, its somewhat bloated, and that's fair. > > That said, the RT people want a simple waitqueue, one that has > > deterministic behaviour. This is only possibly by removing some of the > > more obscure waitqueue features and thus also results in a slimmer > > structure. > > Oh really? That's good to hear. http://thread.gmane.org/gmane.linux.kernel/1808752 is the last posting iirc. > I do like wake_all() being cheaper with the singly linked list, wakups are > much > more common than waiting on things (e.g. the aio code delivering events to the > ringbuffer, anything that's freeing up resources). > > Been kind of wondering how sane it would be to implement > finish_wait()/wake_one() with a singly linked list, and maybe preserve some of > the locklessness. You do fancy lockless stuff too, don't you? Maybe you have > some ideas :) Ha! I think I implemented the required nightmare, have a look at: fb0527bd5ea9 ("locking/mutexes: Introduce cancelable MCS lock for adaptive spinning") MCS locks are basically a single linked lockless FIFO queue, however for the optimistic spinning stuff we needed to be able to abort the lock op/unlink ourselves. I'll be the first to admit that that code is somewhat mind bending. I had to draw quite a few doodles when writing that code :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/