Date: Wed, 5 Jul 2000 11:28:35 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Paterson <cp@bsdi.com> Cc: Greg Lehey <grog@lemis.com>, David Greenman <dg@root.com>, freebsd-smp@freebsd.org Subject: Re: SMP progress (was: Stepping on Toes) Message-ID: <200007051828.LAA88574@apollo.backplane.com> References: <200007051652.KAA14768@berserker.bsdi.com>
index | next in thread | previous in thread | raw e-mail
:} Jake Burkholder is porting the BSD/OS mutexes. I don't expect there
:} to be much of a difference in regards to your heavy-weight interrupt
:} work. I'm going to take a look at Jake's patchset tonight. I think
:} the only operational item we need to research is the sti/cli stuff in
:} the BSDI mutexes... we should be able to remove them at some point
:} (my interrupt code is already using the ipending mechanism to deal
:} with the scheduler mutex being active on the current cpu).
:}
:} If Jake's removed that, then we'll want to put it back in at some point
:} since it saves a significant amount of overhead ('sti' and 'cli' are
:} expensive instructions).
:}
:} -Matt
:} Matthew Dillon
:} <dillon@backplane.com>
:
:
: I believe ipending wants to go away totally. It really
:isn't meaningful in the thread environment and the locked operations
:needed to support it once multiple processor are running
:in the kernel are more expensive the sti, cli.
:
:Chuck
They're less expensive overall. Think about it... how many times
do you get and release the scheduler lock verses how many interrupts
you take in a second. In a loaded system we might be doing
10,000 scheduler lock operations a sec, or more, but still only be
doing 800 interrupts/sec. It's a matter of streamlining the
critical path. This is why cli/sti was removed from the spl*() code
in the first place.
If we are going to be using mutexes heavily, being able to remove the
cli/sti will cut the mutex overhead by around 35%, and more if there is
no contention for the mutex.
I think ipending should stay in. Having the flexibility may prove
useful. For example, if one cpu can't take an interrupt due to holding
the scheduler lock another idle cpu can take it and at least get
most of the state pushed before spinning on the scheduler mutex.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007051828.LAA88574>