Nod.
> For example, when we take serial or networking interrupts at a high
> speed, we'd often be much better off buffering them for a while, and
> then do the bottom half handler as a tight loop. Much better icache
> behaviour, and often you can get other advantages of aggregation
> (especially for the simple cases like serial reception).
The trick is scheduling the rest of the work "after a while".
> > The simple rule: "if you haven't registered/marked active a BH, then
> > you aren't going to trigger BH processing, so don't worry about it"
> > seems like the right thing.
>
> That's essentially the rule now. It's simple, and it works. However, it
> doesn't give us aggregation - which could improve throughput and CPU
> usage.
>
> (Aggregation tends to be bad for latency, which is why it's hard:
> there needs to be some way for the interrupt handler to tell the
> system that "I want bh's run _now_, because I got an important
> packet or I'm close to filling up the queues").
Well, why not have the driver register a BH but not mark it? When the
handler determines that BH processing is now required, it marks the
BH.
It seems to me that you don't need any infrastructure changes to
accomplish this: both the hardirq and softirq semantics are already
set up for this. No SA_INTERRUPT or return flag are needed.
> I don't know if it's really worth pursuing, though.
Seems to me it's up to each driver writer. As infrastructure provider
you've already provided the necessary building blocks.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/