[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RT patch acceptance
    On Thu, 2005-05-26 at 16:38 -0400, john cooper wrote:
    > Andi Kleen wrote:
    > > What I dislike with RT mutexes is that they convert all locks.
    > > It doesnt make much sense to me to have a complex lock that
    > > only protects a few lines of code (and a lot of the spinlock
    > > code is like this). That is just a waste of cycles.
    > I had brought this up in the dim past in the context
    > of adaptive mutexes which could via heuristics decide
    > whether to spin/sleep.

    > > But I always though we should have a new lock type that is between
    > > spinlocks and semaphores and is less heavyweight than a semaphore
    > > (which tends to be quite slow due to its many context switches). Something
    > > like a spinaphore, although it probably doesnt need full semaphore
    > > semantics (rarely any code in the kernel uses that anyways). It could
    > > spin for a short time and then sleep.
    > Spin if the lock is contended and the owner is active
    > on a cpu under the assumption the lock owner's average
    > hold time is less than that of a context switch. There
    > are restrictions as once a path holds an adaptive
    > mutex as a spin lock it cannot acquire another adaptive
    > mutex as a blocking lock.

    It might be simpler to get things working with a basic implementation
    first, (status quo), and then look into adding something like this.

    I don't see how this approach decreases the complexity of the task at
    hand, especially not in regards to concurrency.

    > > If you drop irq threads then you cannot convert all locks
    > > anymore or have to add ugly in_interrupt()checks. So any conversion like
    > > that requires converting locks.
    > Yes, I was trying to make that point in an earlier thread.

    My original comment was:

    > The IRQ threads are actually a separate implementation.
    > IRQ threads do not depend on mutexes, nor do they depend
    > on any of the more opaque general spinlock changes, so this
    > stuff SHOULD be separated out, to eliminate the confusion..
    > As a logical prerequisite to the Mutex stuff, the IRQ threads,
    > if broken out, could allow folks to test the water in the shallow end
    > of the pool.

    The dependency was STATED: "as a logical prerequisite...".
    The context was: "breaking the IRQ threads into a separate patch"

    You misread it, and then commented on that.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-26 23:11    [W:0.021 / U:16.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site