Subject: Re: newlock
To: None <tech-kern@NetBSD.org>
From: Joerg Sonnenberger <email@example.com>
Date: 09/06/2006 18:29:32
On Wed, Sep 06, 2006 at 09:00:26AM -0700, Bill Studenmund wrote:
> On Wed, Sep 06, 2006 at 07:59:21AM +0200, Joerg Sonnenberger wrote:
> > On Tue, Sep 05, 2006 at 03:40:39PM -0700, Bill Studenmund wrote:
> > > Another would be an iSCSI initiator where splbio() and splnet() get
> > > mingled. And heven help someone trying to do iSCSI over ppp. :-)
> > >
> > > Other examples would be (could be) where vnd on NFS mingles splbio() and
> > > splnet().
> > How much sense do the various IPL levels actually make when a fast spin
> > lock (which basically has to block local interrupts anyway) is available?
> A lot. The IPL levels are how we tell a "fast spin lock" what interrupt to
> actually block.
Well, considering e.g. the network stack, two main serialisation points
(a) inside the network stack to protect data structures like the routing
table, the socket list etc.
(b) the interface between network stack and network interfaces
The problem (a) can be handled by multiple threads using *internal*
locks. This does not need any further IPL protection.
Interrupts only affect the (b), so the interface queue and the netisr have to be
protected from concurrent access from the network stack and the interrupt
of the nic. This access can protected by a spin lock as well, as long as
it blocks that interrupt. For that the IPL can be replaced with a check
whether the spin lock is already waited on by the local CPU. When
constraining the use of spin locks to single "interrupt" blocking lock,
this can be done cheap.
For other subsystems similiar approaches should be possible.