lkml.org 
[lkml]   [2010]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when starting KVM
    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@redhat.com>
    >> Reported-by: Kent Overstreet<kent.overstreet@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?


    \
     
     \ /
      Last update: 2010-03-30 20:11    [W:4.324 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site