Date: Tue, 17 Apr 2001 18:33:20 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Greg Lehey <grog@lemis.com>, Alfred Perlstein <bright@wintelcom.net>, "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net>, "current @ freebsd . org" <current@FreeBSD.ORG> Subject: Re: Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost) Message-ID: <200104180133.f3I1XKv16604@earth.backplane.com> References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <20010418093212.A80877@wantadilla.lemis.com> <200104180047.f3I0lN615938@earth.backplane.com> <20010417212045.B14803@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: You cannot be pre-empted by an interrupt if you are holding a spin
: mutex, AFAIK, even under present implementation.
Since spin mutexes are going to be held all over the place, this
type of restriction would seem to be detrimental. If you can do all
the checking up-front it is also unnecessary.
: What happens if we get an interrupt, we're thinking about servicing
:it, about to check whether we're already holding a mutex that may potentially
:be used inside the mainline int routine, and another CPU becomes idle?
:In this particular case, let's say that we decide that we have to set
:ipending and iret immediately, because we're already holding a potential
You could, but you are talking about a very small window of opportunity
assuming that we are running similar code to what we have now in regards
to assigning the interrupts to a cpu. In 4.x we assign interrupts to
whichever cpu is holding Giant. With mutexes we would want to assign
interrupts to whichever cpu is idle and if no cpu is idle we round-robin
the interrupt assignments (e.g. cpu takes interrupt, assigns all
interrupts to the next cpu if no cpus are idle). With that in place,
the best course is almost certainly going to be to do nothing ... that is,
take the interrupt even though it might not be optimal.
If once every X thousand interrupts we happen to hit a case where a cpu
remains idle when it doesn't have to be, who gives a flying f**k if
that one interrupt is non-optimal? I'm not kidding... that sort of
case is not a problem that needs to be solved.
: Also, some mainline interrupt code may need to acquire a really
:large number of locks, but only in some cases. Let's say we have to first
:check if we have a free cached buffer sitting somewhere, and if not, malloc()
None of our current interrupt code needs to aquire a huge number of
locks, and if some piece of interrupt code is so complex that it does,
it should be relegated to a software interrupt (e.g. like the TCP stack).
Lets not create problems where they don't exist. If one of our subsystems
happened to be require more complexity - for example, the I/O completion
handling (biodone() code), it's a solveable problem.
Simplification is what is needed here. Creating a complex solution to
a complex problem only results in a mess. Simplifying the problem so
that it covers most of your codebase and then focusing on the one or two
cases it doesn't cover would seem to be a better way of dealing with
the issue.
:lock operations, but only in the case where we lack the cached buffer to
:allocate it. There is no practical way of telling up front whether or not
:we'll have to malloc(), so I'm wondering how efficiently we would be able
:to predict in cases such as these?
:
:Cheers,
:--
: Bosko Milekic
It could very well be that for an interrupt we might need to list
two mutexes --- one for the memory subsystem and one for the interrupt's
subsystem. It would be nice if we could get away with one, but having
to list two or even three mutexes would not be much of a burden on
the interrupt code.
-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?200104180133.f3I1XKv16604>