From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 25 Mar 2008 23:48:20 -0400

quoted text
> Jeff Garzik wrote:
> > I am being realistic...  it's
> > 
> > * not needed
> > * increases code size
> > * increases number of CPU instructions executed
> > * not needed
> 
> I also wonder if using spin_lock_irqsave() makes moving to a real-time 
> kernel with interrupt threads more difficult for that driver.
> 
> And of course we're talking about a hot path here.

First, if you mention CPU instructions executed you're
totally ignoring what I wrote.  Which is that we're
about to sit spinning on hundreds of cycles doing a PIO
read on a status register.

Those hand full of cycles doing the irqsave/irqrestore don't matter,
at all.

Again, you're arguing for 18 cycles or so out of say 800.
It's peanuts, at best.

Secondly, this isn't a hot path.  The "hot path" is in the
->poll() handler which does all of the real packet RX work.
And that runs lockless, in software interrupt context.

The HW interrupt handler's cost is lower bound by the cost of doing a
PIO on the status register, it's impractical to perform any
micro-optimizations of any sort here.

Especially those that sacrifice consistency.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/