Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

[Ingo Molnar]

* Jens Axboe <axboe@xxxxxxx> wrote:

> It has to go, why? Because your deadlock detection breaks? Doesn't
> seem a very strong reason to me at all, sorry.

no, this is no reason at all. I'm really sorry this issue came up in
this context because now people appear to be arguing this as some sort
of policy issue, implying that is somehow improper to use mutexes
instead of completions, which it clearly is _not_. I very much wanted to
avoid this particular type of flamewar :-)

Using mutexes for completion purposes is perfectly fine kernel code. 
Full stop.

Using completions instead of mutexes in certain cases has some minor
advantages for two simple reasons: it's slighly faster and it's also
more readable.

here's an example: initially i made the scheduler's migration logic use
semaphores in that fashion and Linus made me change it to completions,
because, and i quote Linus here:

 [...]
 Btw, should you not use completions here?

 Completions are optimized for the sleep (ie contention) case, while
 semaphores are optimized for the non-contention case. It also makes 
 more "sense" from a conceptual angle (you're waiting for something to
 complete, not asking for an exclusive thing).
 [...]

and i have to say the migration code did become cleaner. To signal some
sort of event it's a more intuitive _symbol_ _name_ to use 'complete()'
and 'wait_for_completion()' than to use 'up()' and 'down()'.

[ If you truly do not agree with this contention then please just look
at one simple conversion we did and check out the previous and the new
logic, by reading the full previous code and the full resulting code. I
do believe that if anyone at that point still thinks that the
semaphore-based code is just as readable (in that context!) as the
completion-based code that then his brains are not made of neurons but
silicon :) ]

but it has never been kernel policy to not allow the use of mutexes that
way! In some cases it's somewhat cleaner to use completions (and if
something is cleaner in Linux then in most cases it's faster as well),
but it's a judgement thing just like it's judgement thing whether to use
kmalloc() or get_free_pages(). Both are correct for the generic problem
of 'allocate some kernel RAM', but optimized for two different types of
uses.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/