From: Peter Zijlstra <peterz@infradead.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org, avi@redhat.com,
aarcange@redhat.com, akpm@linux-foundation.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Ingo Molnar <mingo@elte.hu>, tglx <tglx@linutronix.de>
Subject: Re: [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when starting KVM
Date: Tue, 30 Mar 2010 19:56:42 +0200 [thread overview]
Message-ID: <1269971802.5258.524.camel@laptop> (raw)
In-Reply-To: <20100330133634.2f1bf3d6@cuia.bos.redhat.com>
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.
Also, you'll need to convince mingo and tglx too.. taking that many
spinlocks is utter suckage..
> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> index d5b3876..e74108f 100644
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -14,8 +14,8 @@
> * We put the hardirq and softirq counter into the preemption
> * counter. The bitmask has the following meaning:
> *
> - * - bits 0-7 are the preemption count (max preemption depth: 256)
> - * - bits 8-15 are the softirq count (max # of softirqs: 256)
> + * - bits 0-12 are the preemption count (max preemption depth: 4096)
> + * - bits 13-19 are the softirq count (max # of softirqs: 256)
> *
> * The hardirq count can in theory reach the same as NR_IRQS.
> * In reality, the number of nested IRQS is limited to the stack
> @@ -24,16 +24,16 @@
> * hardirq nesting. An arch may choose to give less than 10 bits.
> * m68k expects it to be 8.
> *
> - * - bits 16-25 are the hardirq count (max # of nested hardirqs: 1024)
> - * - bit 26 is the NMI_MASK
> - * - bit 28 is the PREEMPT_ACTIVE flag
> + * - bits 26-29 are the hardirq count (max # of nested hardirqs: 1024)
> + * - bit 30 is the NMI_MASK
> + * - bit 31 is the PREEMPT_ACTIVE flag
> *
> - * PREEMPT_MASK: 0x000000ff
> - * SOFTIRQ_MASK: 0x0000ff00
> - * HARDIRQ_MASK: 0x03ff0000
> - * NMI_MASK: 0x04000000
> + * PREEMPT_MASK: 0x00000fff
> + * SOFTIRQ_MASK: 0x000ff000
> + * HARDIRQ_MASK: 0x3ff00000
> + * NMI_MASK: 0x40000000
> */
> -#define PREEMPT_BITS 8
> +#define PREEMPT_BITS 12
> #define SOFTIRQ_BITS 8
> #define NMI_BITS 1
>
>
next prev parent reply other threads:[~2010-03-30 17:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 17:36 [PATCH] increase PREEMPT_BITS to 12 to avoid overflow when starting KVM Rik van Riel
2010-03-30 17:56 ` Peter Zijlstra [this message]
2010-03-30 18:05 ` Rik van Riel
2010-03-30 18:34 ` Peter Zijlstra
2010-04-01 9:40 ` [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all_locks() Avi Kivity
2010-04-01 10:31 ` Peter Zijlstra
2010-04-01 11:04 ` Thomas Gleixner
2010-04-01 11:13 ` Avi Kivity
2010-04-01 11:16 ` Peter Zijlstra
2010-04-01 11:19 ` Avi Kivity
2010-04-01 15:36 ` Andrea Arcangeli
2010-04-01 15:39 ` Avi Kivity
2010-04-01 15:54 ` Andrea Arcangeli
2010-04-01 16:02 ` Avi Kivity
2010-04-01 16:12 ` Andrea Arcangeli
2010-04-01 11:17 ` Avi Kivity
2010-04-01 11:27 ` Peter Zijlstra
2010-04-01 11:43 ` Peter Zijlstra
2010-04-01 11:47 ` Avi Kivity
2010-04-01 15:42 ` Andrea Arcangeli
2010-04-01 15:50 ` Peter Zijlstra
2010-04-01 15:56 ` Peter Zijlstra
2010-04-01 16:07 ` Andrea Arcangeli
2010-04-01 16:32 ` Peter Zijlstra
2010-04-01 16:00 ` Andrea Arcangeli
2010-04-01 15:51 ` Avi Kivity
2010-04-01 15:56 ` Peter Zijlstra
2010-04-01 16:06 ` Avi Kivity
2010-04-01 16:15 ` Paul E. McKenney
2010-04-01 16:36 ` Peter Zijlstra
2010-04-01 17:02 ` Paul E. McKenney
2010-04-01 16:08 ` Andrea Arcangeli
2010-04-01 16:14 ` Paul E. McKenney
2010-04-01 16:02 ` Andrea Arcangeli
2010-04-01 16:12 ` Peter Zijlstra
2010-04-01 16:18 ` Andrea Arcangeli
2010-04-01 16:45 ` Peter Zijlstra
2010-04-01 16:49 ` Peter Zijlstra
2010-04-01 17:04 ` Andrea Arcangeli
2010-04-01 14:16 ` Rik van Riel
2010-04-01 15:32 ` Andrea Arcangeli
2010-04-01 15:37 ` Avi Kivity
2010-04-01 11:09 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1269971802.5258.524.camel@laptop \
--to=peterz@infradead.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=avi@redhat.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.