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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Jan 2001, Matthew Jacob wrote:
> > On Tue, 2 Jan 2001, Matthew Jacob wrote:
> >=20
> > > 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 inheri=
ts the
> > > priority of the ithread until it releases the lock that caused it to =
be
> > > resumed.
> >=20
> > Just a tiny question and remark:
> >=20
> > We must keep in mind (at it I have this in mind) that IPL is a thing lo=
cal
> > to a CPU but MUTEXes are global synchronisation objects.
>=20
> That's absolutely correct.
>=20
> > What happens if a ithread want to acquire a MUTEX owned by a thread=20
> > running on another CPU ?
> >=20
> > In my $0.02 humble opinion, I think that we should probably be able fro=
m
> > an ithread to just spinlock on a MUTEX that is already owned, unless we
> > are believing in miracles.
>=20
> 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- t=
he
> ithread that tries to snag a lock that's held elsewhere will cause a
> reschedule.
>=20
> For a single CPU case, the thread that holds the lock should be resumed s=
o the
> lock can be freed up as soon as possible. For the multiple CPU case, a sp=
in
> should occur. The net result is the same- the ithread wanting the lock th=
at's
> held elsewhere has to wait until that lock is clear. We've been fussing m=
ostly
> over the issue that interrupt passivating doesn't seem to occur as cleanl=
y 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=20
corresponding IPLs.
Is this too simple or what did I miss ?
> What will help get rid of the awful inefficiencies that this will bring i=
n
> 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 w=
here
> 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=E9rard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10101022138490.1669-100000>