Subject: Re: splx() optimization [was Re: SMP re-eetrancy in "bottom half" drivers]
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-kern
Date: 06/01/2005 16:04:52
In message <1117605671.211271.5554.nullmailer@yamt.dyndns.org>YAMAMOTO Takashi writes
>hi,
>
>> If we start going down route of making the network stack even partially
>> SMP-safe, then I think the consensus on tech-kern is that we'll also
>> need to head in the direction of making all interrupts ordered; with
>> associated, hierarchically-ordered (spin)locks at each level.
>
>i didn't notice such a consensus.  can you give me a pointer?
>

hi,

I thought I saw a conensus in the last 2 or 3 weeks, after I reposted
your experimental patch from December 2003?  The developers who I
recall as objecting strongly to an interrupt/spl hierarchy, in
discussion back around January 2004, now say they don't object.
At least that's what I recall from May.

If you still object to that approach, or don't see a need (see below)
then I inadvertentlyv misteook silence for acquiesence, I now stand
corrected, and I must apologize: I'm very sorry, Yamamoto-san.

>i don't see any needs to have all interrupts ordered.

The issue I see is: how can we move interrupt handlers outside the
biglock, whilst preserving existing spl() semantics, and yet stay
deadlock-free?  Ordering of both interrupts and SPLs seems to be the
way to go, at least for now.

>i won't object if you want to make them ordered as
>a transient convention, tho.

I don't see how else to proceed for now (save to flatten all device
interrupts to a single level, as in the experimental part of your
patch; or as you described it to Stephan.)

I view (interrupt,spl) ordering as an interim solution, until we find
a better approach.  If you see a better way now, then I am most keen
to hear it.

regards,
--Jonathan