On Sat, Oct 05, 2013 at 10:04:16AM +0200, Ingo Molnar wrote: > > * Peter Zijlstra <pet...@infradead.org> wrote: > > > On Fri, Oct 04, 2013 at 10:44:05PM +0200, Peter Zijlstra wrote: > > > > > > slightly related; do we want to do something like the following two > > > patches? > > > > and > > Yeah, both look good to me - but I'd move them into > kernel/sched/completion.c and kernel/sched/wait.c if no-one objects.
Do you also want to suck in semaphore.c mutex.c rwsem.c spinlock.c etc? Or do you want to create something like kernel/locking/ for all that. I don't really mind too much either way except that I think that wait.c and completion.c on their own make for a somewhat random split or primitives. > > --- /dev/null > > +++ b/kernel/completion.c > > @@ -0,0 +1,287 @@ > > + > > +#include <linux/sched.h> > > +#include <linux/completion.h> > > Also, mind adding a small blurb at the top explaining what it's all about? > Just one sentence or two. It got a bit longer: +/* + * Generic wait-for-completion handler; + * + * It differs from semaphores in that their default case is the opposite, + * wait_for_completion default blocks whereas semaphore default non-block. The + * interface also makes it easy to 'complete' multiple waiting threads, + * something which isn't entirely natural for semaphores. + * + * But more importantly, the primitive documents the usage. Semaphores would + * typically be used for exclusion which gives rise to priority inversion. + * Waiting for completion is a typically sync point, but not an exclusion point. + */ -- 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/
