increase PREEMPT_BITS to 12 to avoid overflow when starting KVM
in [Kernel]
|
From: Rik van Riel on 30 Mar 2010 14:10 On 03/30/2010 01:56 PM, Peter Zijlstra wrote: > On Tue, 2010-03-30 at 13:36 -0400, Rik van Riel wrote: >> Increase the PREEMPT_BITS to 12, to deal with a larger number >> of locks that can be taken in mm_take_all_locks or other places >> where many instances of the same type of lock can be taken. >> >> The overflow of PREEMPT_BITS should be harmless, since it simply >> increments the counter into the SOFTIRQ_BITS, and the counter >> will be decremented again later. >> >> However, the overflow does lead to backtraces with CONFIG_PREEMPT_DEBUG >> enabled. >> >> Signed-off-by: Rik van Riel<riel(a)redhat.com> >> Reported-by: Kent Overstreet<kent.overstreet(a)gmail.com> >> >> --- >> Kent, does this patch fix the issue you saw? >> >> Peter, I know you do not like this approach. However, I could not >> think of a way around mm_take_all_locks. We need to take those locks >> and want to track that fact for lock debugging... > > Does this even boot? It tramples all over PREEMPT_ACTIVE for x86. Awww nuts. I thought PREEMPT_ACTIVE used the same scheme of adding shifts, but now I see it is hard coded on x86. Doh! I'm guessing the best thing to do would be to remove the PREEMPT_ACTIVE #define on x86 and use the one from hardirq.h? > Also, you'll need to convince mingo and tglx too.. taking that many > spinlocks is utter suckage.. No argument there. I can't think of an alternative to mm_take_all_locks though. Andrea? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: Linux 2.6.34-rc3 Next: sound: fix patch_realtek printk format |