Date: Tue, 2 Jan 2001 22:16:40 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Matthew Jacob <mjacob@feral.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, alpha@FreeBSD.ORG, Doug Rabson <dfr@nlsystems.com> Subject: RE: Interrupt threads Message-ID: <Pine.LNX.4.10.10101022138490.1669-100000@linux.local> In-Reply-To: <Pine.LNX.4.21.0101021303460.14503-100000@zeppo.feral.com>
index | next in thread | previous in thread | raw e-mail
On Tue, 2 Jan 2001, Matthew Jacob wrote:
> > On Tue, 2 Jan 2001, Matthew Jacob wrote:
> >
> > > You switch to the process w/o changing IPL. It is resumed at the IPL of the
> > > ithread that blocked. In the software way of looking at it, it inherits the
> > > priority of the ithread until it releases the lock that caused it to be
> > > resumed.
> >
> > Just a tiny question and remark:
> >
> > We must keep in mind (at it I have this in mind) that IPL is a thing local
> > to a CPU but MUTEXes are global synchronisation objects.
>
> That's absolutely correct.
>
> > What happens if a ithread want to acquire a MUTEX owned by a thread
> > running on another CPU ?
> >
> > In my $0.02 humble opinion, I think that we should probably be able from
> > an ithread to just spinlock on a MUTEX that is already owned, unless we
> > are believing in miracles.
>
> This is why Solaris (and FreeBSD) makes a distinction between Spin and
> Adaptive locks. The default we have for all of this are adaptive locks- the
> ithread that tries to snag a lock that's held elsewhere will cause a
> reschedule.
>
> For a single CPU case, the thread that holds the lock should be resumed so the
> lock can be freed up as soon as possible. For the multiple CPU case, a spin
> should occur. The net result is the same- the ithread wanting the lock that's
> held elsewhere has to wait until that lock is clear. We've been fussing mostly
> over the issue that interrupt passivating doesn't seem to occur as cleanly as
> we'd like on all platforms.
OK for the mutex model, but possibly, there is no need to passivate
interrupts nor tamper too much with IPLs, in my theory (may-be too
simplistic).
The harware will raise IPL as needed and interrupt handling return stuff
will restore previous IPL as needed (Higher IPLs will nest). We just have
to handle _software_ priorities and priority inheritance accordingly to
current IPL in order not to deadlock if we have to reschedule.
In other words, software priorities must be monotonic with regards to
corresponding IPLs.
Is this too simple or what did I miss ?
> What will help get rid of the awful inefficiencies that this will bring in
> will be the active rewriting of drivers to choose locking strategies that will
> avoid this. We're very early in this stage so that we have broad swaths where
> things Just Don't Work Well(tm).
May be, in the future, a new driver model that would consist in:
- A 'as fast as possible' upper half that gets the interrupt condition and
clear it at device side, and avoid contentions as possible.
and,
- a lower half that can run in another context (thread of whatever
can allow interrupts)
Gérard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10101022138490.1669-100000>