public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
	Natalie Protasevich <Natalie.Protasevich@unisys.com>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] i386 irq: Kill NR_IRQ_VECTORS and increase NR_IRQS
Date: Fri, 16 Feb 2007 03:33:32 -0700	[thread overview]
Message-ID: <m1y7mye6ir.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <200702161115.59017.ak@suse.de> (Andi Kleen's message of "Fri, 16 Feb 2007 11:15:58 +0100")

Andi Kleen <ak@suse.de> writes:

>> Allowing the kernel to work on big machines without complicated
>> and error prone irq remapping logic.
>
> How much memory does this use by default? If it's much there should
> be at least a CONFIG_* to make it smaller.

If you don't build a generic kernel and are not a big way smp you only
get 200 IRQs so it is less.  

Otherwise it is either 1024 or NR_CPUS*32 depending on the subarch
we compile.  The limits are actually unchanged from what we are doing
today.

I'm in the final stages of figuring out how to kill the stupid
irq_desc array which should make all the memory consumption worries
go away but that is a little ways off, and I'm putting real bug
fixes ahead of that work.

Basically this is just a back port from x86_64 without the
complication of the per cpu vector logic.  So if we run into any
issues I missed before this reaches a stable kernel we can just copy
the fix from x86_64 where we have been doing this for a while.  

So in short the existing CONFIG_ options should give us the control
we need, and before it becomes any kind of an issue I intend to
completely remove the compile time limit and make it dynamic.

Eric

      reply	other threads:[~2007-02-16 10:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16  5:15 [PATCH] i386: irq: Kill IRQ compression Len Brown
2007-02-16  7:44 ` Eric W. Biederman
2007-02-16  9:21   ` Eric W. Biederman
2007-02-16  9:51 ` [PATCH] i386 irq: Kill NR_IRQ_VECTORS and increase NR_IRQS Eric W. Biederman
2007-02-16 10:15   ` Andi Kleen
2007-02-16 10:33     ` Eric W. Biederman [this message]

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=m1y7mye6ir.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=Natalie.Protasevich@unisys.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox