Subject: Re: newlock
To: None <>
From: Bill Studenmund <>
List: tech-kern
Date: 09/06/2006 11:09:05
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 06, 2006 at 06:29:32PM +0200, Joerg Sonnenberger wrote:
> On Wed, Sep 06, 2006 at 09:00:26AM -0700, Bill Studenmund wrote:
> > A lot. The IPL levels are how we tell a "fast spin lock" what interrupt=
> > actually block.
> Well, considering e.g. the network stack, two main serialisation points
> exist:
> (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 hav=
e 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.

I think we're speaking past each other.

The IPL can not be replaced as you describe, because the IPL itself is not=
used as you describe. The code used as you described, the splxxx() calls,=
will be replaced with interupt-blocking mutexes. See Darrin's discussion=20
of this months ago, and a number of other posts.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)