lkml.org 
[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

    * Jens Axboe <axboe@suse.de> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:07    [W:4.270 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site