Linus Torvalds a écrit :
So I suspect that the _real_ fix is:
- for 2.6.14: remove the batching limig (or just make it much higher for
now)
I would just remove it. If the limit is wrong, we crash again. And the
realtime guys already are pissed off by batch=10000 anyway.
- post-14: work on making sure rcu callbacks are done in a more timely
manner when the rcu queue gets long. This would involve TIF_RCUPENDING
and whatever else to make sure that we have timely quiescent periods,
and we do the RCU callback tasklet more often if the queue is long.
Absolutely. Keeping a count of (percpu) queued items is basically free if kept
in the cache line used by list head, so the 'queue length on this cpu' is a
cheap metric.
A 'realtime refinement' would be to use a different maxbatch limit depending
on the caller's priority : Let a softirq thread have a lower batch count than
a regular user thread.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
