Messages in this thread |  | | Date | Fri, 28 Sep 2001 18:46:16 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] softirq performance fixes, cleanups, 2.4.10. |
| |
On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
> he's allowing to repeat the loop more than once to hide it, [...]
it's not done to 'hide' it in any way. I removed the mask method because it's redundant under the new scheme.
Softirqs *cannot* be handled 'fairly', there is always going to be one that is called sooner, and one that is called later, and even with the old code, their position within the bitmask decides which one goes first.
> to do the "mask" with repetition correctly we'd need a per-softirq > counter, not just a bitmask so it wouldn't be handy to allocate on the > stack, but it's nothing unfixable.
with a repetition count of 10, there is no difference, and no reason to add the mask mechanizm again. (In fact it will statistically more fair because we 'interleave' the softirqs in a fair pattern.)
to make it easier to compare, here are verbal descriptions of the two mechanizms. (for those who have *cough* trouble understanding the patch.)
the old code's "mask method": it starts processing softirqs in strict order. It will reprocess any softirq (in strict order again) that got reactivated meanwhile, but it will only process softirqs that were not processed yet during this run.
it's not roundrobin, and it's not fair in any way, there is a strict priority between softirqs, with the additional twist of processing softirqs that got activated meanwhile. This concept is completely meaningless, it neither tries to process all pending softirqs, nor does it try implement some simple policy, like 'process all softirqs that are active *now* and *once*'.
the new method does a simple loop (in priority order, first HI, then TX, then RX and LO) over all currently active softirqs, then it does a (limited) loop over all of them again if some softirq got activated while these were processed.
Ingo
- 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/
|  |