Hi,
On Wed, Sep 08, 2004 at 07:21:06PM +1000, Con Kolivas wrote:
Andreas Mohr wrote:
Some more explanation: AFAIK unlikely() should only be used when you're damn sure that this will NEVER occur (e.g. failure cases), since it will artificially aggravate penalty of this check in case it does occur. IRQ sharing is *much* too common to justify using unlikely() here. *ESPECIALLY* since IRQ sharing is very latency critical!
The magnitude of it's effect is overstated somewhat. Firstly we're talking about a delay in the nanosecond range, and second the cpu will optimise that out if it finds it's a frequently used path. Despite all that, however, I agree it's probably inappropriate. {un}likely() should be used for a path that is always/never traversed except in fault handling, jiffy wrap etc.
True, it shouldn't make too much of a difference.
BTW, I just checked linux-2.6.8.1/sound/pci/intel8x0.c , and to me it seems it doesn't take IRQ sharing into account at all.
Would it be useful to carefully optimize many IRQ handlers for IRQ sharing and send you a patch for inclusion in -ck?
If you could demonstrate some objective benefit I think akpm would even be interested in putting such a thing in -mm.
Cheers, Con
signature.asc
Description: OpenPGP digital signature
