Therre is a really good cause for avoiding bh processing on every
interrupt, and that's "locality".
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 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").
I don't know if it's really worth pursuing, though.
Linus
-
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/