:I can't see any major problem with this but I can't help thinking that
:there must be one.. on UP the question is: "who is going to 
:release the lock if no-one is runnable?"

    An interrupt, of course.  Wakeups don't happen out of thin air!  This
    is true of 1.x, 2.x, 3.x, 4.x, 5.x, UP, and SMP.  Something needs to
    trigger the event that causes the wakeup to occur.

:can you detail in more clarity the flip-flopping you were seeing?

    Basically what is happening is that switch/wakeup overhead is being
    imposed unnecessarily.  There is no need to switch if there is nothing
    to switch to, and this also causes the other process to not have to
    wakeup anyone when it releases Giant because process #1 is spinning
    on it instead of sleeping on it.  So you immediate remove four context
    switches from the critical path.

    The other problem I saw is actually a fairly typical problem.  When you
    have multiple cpu's running the same program that is making a system
    call that obtains a mutex, and the mutex spins, the programs will
    tend to stabilize slightly out of sync of each other so the
    mutex-release in one occurs just before the mutex-acquire in another.
    The result is fairly optimal performance for this particular situation
    even though the mutexes are spinning.

    However, when the mutex sleeps instead of spins no such stabilization
    occurs.  Sometimes I would run the two-process test and they would
    operate optimally... obviously they were out of sync enough so there
    was no mutex contention in the one remaining Giant mutex in userret.
    Sometimes they would operate non-optimally, showing half the performance.
    Even worse, this non-optimal performance appears to stabilize.. i.e.,
    it can't break out of it once it gets into it.

    So what this code does is avoid both the sleep, the context switch,
    and the wakeup in situations where they are not needed and reduces
    syscall overhead by about 100% per cpu with 2 cpus.  It almost certainly
    also avoids.


    In regards to preemption code, I think this is a separate issue.  This
    case occurs when there are no runnable processes waiting for cpu in the
    system (i.e. running processes are already on their cpus).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to