DragonFly kernel List (threaded) for 2005-06
Re: mtd_cpl question
: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
: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
: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.
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.