In message <1071716524.542505.8922.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi  writes:
>> >it sounds like a regression.

>> I dont see how that can possibly count as a "regression", specially
>> not for the kinds of workload I described earlier.
>
>of course, i have no objection to your goal.
>however, there's no reason to make spl "global".

Hm. As Jason observes, I neglectged the changes that allow hardclock()
interrupts, and was assuming that higher SPLs were already global
(they arent(). In that sense my original proposal was a regression,
though the service rates are typically about 4 orders of magnitude
lower than I would want fo 10gb#.

But, thank you for such a polite phrasing.


>for your purpose, i think what you need are:
>- change lowlevel intr handler (Xintr_* in the case of i386) not to
>  take kernel_lock if the driver is marked as mp-safe.
>- make the driver mp-safe.
>	- change the driver to acquire per-device lock if needed.
>	- change the driver to acquire kernel_lock
>	  (or other fine-grained locks) when needed.

Yes. In more detail:

>- change lowlevel intr handler (Xintr_* in the case of i386) not to
>  take kernel_lock if the driver is marked as mp-safe.

Yes, that was assuedm to be understood when I suggested multiple
CPUs servicing interrupts.

>- make the driver mp-safe.

Yes, of course. :-). that will be the most time-consuming part.


>	- change the driver to acquire per-device lock if needed.

On downcalls (as opposed to interrupts)? Yes. I took that as
understood; it was also assumed in the hypothetical pdeadlock
discussion a message or two back.


>	- change the driver to acquire kernel_lock
>	  (or other fine-grained locks) when needed.

Yes, though we seem to have different preferences on kernel_lock
versus creating more locks. I am willing to be re-educated on that.