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
| ||
|
Date: Thu, 27 Mar 2008 11:16:09 -0500 (CDT) From: Alan Mayer <ajm@....com> To: Ingo Molnar <mingo@...e.hu> Cc: Alan Mayer <ajm@....com>, torvalds@...ux-foundation.org, linux-kernel list <linux-kernel@...r.kernel.org>, Robin Holt <holt@....com>, Jack Steiner <steiner@....com>, Russ Anderson <rja@....com> Subject: Re: [PATCH] x86_64: resize NR_IRQS for large machines (re-submit) > well, i dont it has to be (or it should be) an all or nothing patch, > given the complexity and risks involved. > > - we should first introduce a nr_irqs variable and a Kconfig switch > (say CONFIG_ARCH_HAS_DYNAMIC_NR_IRQS) for architectures to toggle. If > the switch is toggled, nr_irqs is a variable, otherwise it's a carbon > copy of NR_IRQS. Some array-definition, declaration and initialization > wrappers are provided as well. > > - then the core code, x86 and most drivers can be converted to nr_irqs. > The switch might initially even be user-selectable if > CONFIG_DEBUG_KERNEL, to ease regression testing. > > - other architectures will follow one by one, fixing their > arch-dependent drivers as well in the process > > - finally we get rid of the wrappers. > > Ingo > Okay, let's see if I understand this. First patch introduces a config switch and a variable, nr_irqs that is set to NR_IRQS. It also dynamically allocates the currently staticly allocated arrays that are dimensioned by NR_IRQS. It also initializes these dynamically allocated data structures. This is all done under the config switch, initially off by default. Second patch changes core code, x86 and most drivers to use nr_irqs. This patch will also introduce a calculation of nr_irqs, based on interrupt sources, that is a better estimate of the number of irqs in the running system than just picking a guaranteed not-to-exceed value that may be too big. Is there a way to identify which drivers need to be addressed? Then, test the crap out of it. Other architectures will follow, with the work being done by people familiar with those architectures. Clean up anything that's left over that's now been made unnecessary by the conversion by everyone. Including the config option? Do I have the gist of it? --ajm We are star dust, We are golden, We are caught in the Devil's bargain. -- Alan J. Mayer SGI ajm@....com WORK: 651-683-3131 HOME: 651-407-0134 -- -- 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