lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 16 Feb 2007 03:33:32 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andi Kleen <ak@...e.de>
Cc:	Andrew Morton <akpm@...l.org>,
	Natalie Protasevich <Natalie.Protasevich@...sys.com>,
	"lkml - Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org, Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] i386 irq: Kill NR_IRQ_VECTORS and increase NR_IRQS

Andi Kleen <ak@...e.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ