Date: Mon, 18 Feb 2002 12:21:29 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: current@FreeBSD.ORG Subject: Re: Patch to improve mutex collision performance Message-ID: <200202182021.g1IKLTM36110@apollo.backplane.com> References: <Pine.BSF.4.21.0202181140100.52663-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202182021.g1IKLTM36110>