lkml.org 
[lkml]   [2005]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 1/3] mutex subsystem: trylock
    On Thu, 29 Dec 2005, Nick Piggin wrote:

    > FWIW, I still think we should go for an open-coded "cmpxchg" variant
    > for UP that disables preempt, and an atomic_cmpxchg variant for SMP.
    >
    > - good generic implementations
    > - the UP version is faster than atomic_xchg for non preempt on ARM
    > - if you really are counting cycles, you'd probably have preempt off
    > - if you've got preempt on then the preempt_ operations in semaphores
    > would be the least of your worries (how about spinlocks?)
    >
    > Rather than straight out introducing lots of ugliness and complexity
    > for something that actually slows down the speed critical !preempt
    > case (but is unlikely to be measurable either way).

    I provided you with the demonstration last week:

    - the non SMP (ARM version < 6) is using xchg.

    - xchg on ARM version < 6 is always faster and smaller than any
    preemption disable.

    - xchg on ARM is the same size as the smallest solution you may think of
    when preemption is disabled and never slower (prove me otherwise? if
    you wish).

    - all xchg based primitives are "generic" code already.

    And I think you didn't look at the overall patch set before talking
    about "lots of ugliness", did you? The fact is that the code,
    especially the core code, is much cleaner now than it was when
    everything was seemingly "generic" since the current work on
    architecture abstractions still allows optimizations in a way that is so
    much cleaner and controlled than what happened with the semaphore code,
    and the debugging code can even take advantage of it without polluting
    the core code.

    It happens that i386, x86_64 and ARM (if v6 or above) currently have
    their own tweaks to save space and/or cycles in a pretty strictly
    defined way. The effort is currently spent on making sure if other
    architectures want to use one of their own tricks for those they can do
    it without affecting the core code which remains 95% of the whole thing
    (which is not the case for semaphores), and the currently provided
    architecture specific versions are _never_ bigger nor slower than any
    generic version would be. Otherwise what would be the point?


    Nicolas
    -
    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-12-29 18:18    [W:0.026 / U:0.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site