linux-kernel - Re: [patch 00/47] Sparse irq rework

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <m11v8692vo.fsf@fess.ebiederm.org>
Date:	Sun, 03 Oct 2010 18:13:15 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Russell King <linux@....linux.org.uk>,
	David Woodhouse <dwmw2@...radead.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [patch 00/47] Sparse irq rework

Thomas Gleixner <tglx@...utronix.de> writes:

>> I don't know that I have a problem with this but I do have a problem
>> with using a bitmap.  A lot of the kernels irq usage has been distored
>> because we use a compact array, that we cannot grow over time.  Using a
>> bitmap here essentially removes 90% of the point of sparse irq.  The
>> ability to remove a hard coded NR_IRQS from the kernel.
>
> Well, lets look at some (un)realistic numbers:
>
> Assume 16k cores and 32 irqs / core. That's 512k interrupts and
> requires a 64k bitmap.
>
> If we hit that limit, then we have some other more serious problems to
> solve.

Possibly. 

Fundamentally keeping NR_IRQS anywhere I see as a problem, and it
really disturbs me.  Even nr_irqs I see as pretty fishy.

Looking at this objectively I see a bitmap sized to the formula
32*NR_CPUS with NR_CPUS expected to double every 18-24 months.
Which means in a decade our worst case will be 2M not 64k.

Can we please build this with scalable interfaces so we don't have to do
this again in a couple of years, and so we don't have to have little
machines paying the price for big machines, and so that big machines
aren't hamstrung because of data structures built for little machines.

Perhaps this just requires using ida instead of a bitmap.

I really think it is a mistake to use an irq number outside of the
functions in interrupt.h that go to the drivers and the userspace
display functions.

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/