Re: mtd_cpl question

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:On Thu, Jun 02, 2005 at 10:13:10AM -0700, Matthew Dillon wrote:
:>    Have you taken a look at the SPL masks recently?  Just about all major
:>    devices are covered by the most basic SPL anyway, so for all intents and
:>    purposes a splbio() or splvm() is going to be equivalent to a critical 
:>    section.
:
:splbio and splbio for example don't interlock. We already have a slow
:disk IO path, when e.g. network driver can prevent the processing
:of the ATA interrupt, this will even suck more.

    How exactly will it suck?  I mean, here you have a network interrupt
    that requires X amount of cpu to process, and a disk interrupt which
    requires Y amount of cpu to process.  What does it matter that X be
    allowed to interrupt Y ?  It still takes X+Y cpu and the whole mess
    still runs (usually) in less then 100uS anyway. 

    The cost of handling a masked interrupt, worst case, is ~1uS.  You
    can't argue that, say, 400 *masked* interrupts per second (~400uS) would
    have any impact on system performance.

:...
:>    at all, and even then we are only talking about a few microseconds at
:>    worst.
:
:There is a lot of code issuing DELAYs under spl protection. For example,
:almost all MII operations are running in the area of 20ms with common
:NICs. Those are ages on a modern CPU. Yes, this about latency. But not
:serving interrupts for a long time for _any_ device *does* hurt.
:
:Joerg

    DELAYs are used in very few places.  How often is an MII operation
    executed ?  Not often.  Besides, the problem there isn't the spl or
    the critical section, it's the coding of the algorithm.  There are 
    so few places where DELAYs are an issue that we can in fact just fix
    those few places.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>