From: Steven Rostedt <srostedt@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] asm-generic: drop HARDIRQ_BITS definition from hardirq.h
Date: Mon, 15 Jun 2009 11:59:34 -0400 [thread overview]
Message-ID: <1245081574.5195.3.camel@localhost.localdomain> (raw)
In-Reply-To: <200906142243.32409.arnd@arndb.de>
On Sun, 2009-06-14 at 22:43 +0200, Arnd Bergmann wrote:
> linux/hardirq.h contains a fallback for HARDIRQ_BITS to 10
> if it's not defined, so it is pointless to define a default
> of 8 in asm/hardirq.h. There does not seem to be a good
> reason why an architecture would want to limit the number
> of hardirqs this way.
>
> Reported-by: Mike Frysinger <vapier@gentoo.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> include/asm-generic/hardirq.h | 13 -------------
> 1 files changed, 0 insertions(+), 13 deletions(-)
> On Sunday 14 June 2009, Mike Frysinger wrote:
>
> Mike Frysinger wrote:
> > is there any downsides to using a "too large" value ? i.e. if my
> > system has less than 256, does it make any difference at all if it's
> > set to 10 ?
> > -mike
>
> None that I know of. I'm queuing this patch in my asm-generic tree now,
> unless Steven or someone else has a better idea.
ARGH!!! I guess the best patch would be to comment this better. That
"HARDIRQ_BITS" has nothing to do with the number of interrupts a machine
may have. It is the number of nested interrupts a machine may do.
If you plan on having more than 256 interrupts nesting, I suggest you
need to fix the stack problems first ;-)
Please, we only have a few bits in the preempt count (on 32 bit
machines) and this is the number of bits used to record the nesting of
interrupts.
-- Steve
>
> Arnd <><
>
> diff --git a/include/asm-generic/hardirq.h b/include/asm-generic/hardirq.h
> index 3d5d2c9..23bb4da 100644
> --- a/include/asm-generic/hardirq.h
> +++ b/include/asm-generic/hardirq.h
> @@ -11,19 +11,6 @@ typedef struct {
>
> #include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
>
> -#ifndef HARDIRQ_BITS
> -#define HARDIRQ_BITS 8
> -#endif
> -
> -/*
> - * The hardirq mask has to be large enough to have
> - * space for potentially all IRQ sources in the system
> - * nesting on a single CPU:
> - */
> -#if (1 << HARDIRQ_BITS) < NR_IRQS
> -# error HARDIRQ_BITS is too low!
> -#endif
> -
> #ifndef ack_bad_irq
> static inline void ack_bad_irq(unsigned int irq)
> {
next prev parent reply other threads:[~2009-06-15 15:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-13 14:30 [PATCH] asm-generic: uaccess: fix up local access_ok() usage Mike Frysinger
2009-06-13 14:30 ` [PATCH] asm-generic: hard_irqs: handle NR_IRQS > 256 automatically Mike Frysinger
2009-06-13 17:57 ` H. Peter Anvin
2009-06-13 21:18 ` Arnd Bergmann
2009-06-14 0:25 ` Mike Frysinger
2009-06-14 20:43 ` [PATCH] asm-generic: drop HARDIRQ_BITS definition from hardirq.h Arnd Bergmann
2009-06-15 15:59 ` Steven Rostedt [this message]
2009-06-15 16:17 ` Mike Frysinger
2009-06-15 16:44 ` Steven Rostedt
2009-06-16 14:37 ` [PATCH v3] " Arnd Bergmann
2009-06-13 15:59 ` [PATCH] asm-generic: uaccess: fix up local access_ok() usage Mike Frysinger
2009-06-13 20:53 ` Arnd Bergmann
2009-06-14 0:47 ` Mike Frysinger
2009-06-14 10:10 ` Arnd Bergmann
2009-06-14 10:17 ` Mike Frysinger
2009-06-14 10:24 ` Arnd Bergmann
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=1245081574.5195.3.camel@localhost.localdomain \
--to=srostedt@redhat.com \
--cc=arnd@arndb.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vapier.adi@gmail.com \
/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.