Date: Wed, 4 Jul 2001 10:39:23 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org>, Matthew Jacob <mjacob@feral.com> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <200107041739.f64HdN945537@earth.backplane.com> References: <XFMail.010704094047.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>
:> This call seems to implement for wakeup() what msleep() implements for
:> tsleep(), and it makes sense in that context, but it is solving a problem
:> by obfuscating the SMP code even more then it already is, all in the
:> name of avoiding priority inversions using an 'instant-gratification'
:
:Actually, Matt, this doesn't requrie preemption in order to be seen at all.
:It's really quite simple:
:
: cpu A cpu B
: lock A ....
: sleep on A ....
: idle ....
: lock A
: wakeup A
: block on A ....
: unlock A , unblock thread that was on cpu A
: lock A
:
:With mwakeup, this becomes:
:
: cpu A cpu B
: lock A ....
: sleep on A ....
: idle ....
: lock A
: mwakeup A (drops A before doing actual wakeup)
: lock A
Huh? In the above example, why not simply release A before calling
the wakeup function in the above example? mwakeup is not required at all.
You may have to interlock sleeps, but you certainly do not have to
interlock wakeups. Try presenting another example.
In the non-preemptive case, on a UP system, the first task is allowed
to wakeup the second, then unlock, then sleep, and then will switch to
the second task. All without any need for a mwakeup() function.
In the preemptive case, on a UP system, you have to have mwakeup() to
avoid the two extra context switches.
In the non-preemptive case, on a MP system, the scheduling overhead
will take far longer then it takes the original thread to release the
mutex so it does not matter whether the mutex is released before or after
the wakeup.
In the preemptive case, on a MP system, there isn't going to be any
significant difference except that you will wind up blowing the L1 and L2
cpu caches to do the preemption if the system happens to be heavily
loaded... precisely the wrong time, because a heavily loaded system is in
a situation where you want the system to operate as efficiently as
possible. You are already eating time slices due to the load, getting a
kernel thread to run a few microseconds earlier is not going to make a
damn bit of difference in regards to interactive responsiveness and yet
to get those few microseconds you are willing to blow up the cpu caches
AND eat the extra switching overhead. It makes no sense.
-
My assertion is that mwakeup() is solving a problem created by the
preemption in the first place and that assertion still holds true.
This preemption stuff is going to turn performance tuning into a
nightmare. No, I take that back. It has ALREADY turned performance
tuning into a nightmare and it is only going to get worse. By the 5.0
release we are going to have dozens upon dozens of special case API
calls like mwakeup(). We already have too many.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107041739.f64HdN945537>