linux-kernel - RE: [PATCH 0/8] git pull request for tip/tracing/core

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: <alpine.DEB.1.10.0902111320010.15438@gandalf.stny.rr.com>
Date:	Wed, 11 Feb 2009 13:23:21 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Luck, Tony" <tony.luck@...el.com>
cc:	Ingo Molnar <mingo@...e.hu>, Mike Travis <travis@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"isimatu.yasuaki@...fujitsu.com" <isimatu.yasuaki@...fujitsu.com>,
	"kaneshige.kenji@...fujitsu.com" <kaneshige.kenji@...fujitsu.com>
Subject: RE: [PATCH 0/8] git pull request for tip/tracing/core


On Wed, 11 Feb 2009, Luck, Tony wrote:

> > > Before we go and make the change, Peter brought up a good point on IRC. Is
> > > there any reason that ia64 needs 1 << 14 IRQs?  That's 16384!
> > >
> > > Perhaps the better solution wolud be (if possible), to simply lower the
> > > number of bits.
> >
> > i'm the wrong person to be asked about that. (Cc:-ed the right people)
> 
> People build some pretty big systems on ia64.  SGI's largest has 4096
> cpus ... so 16384 IRQs is only 4 per cpu.  That doesn't sound like very
> many to me.
> 
> Fujitsu added the vector domain support for ia64 to get around the shortage
> of IRQs for large machines.  Added them to the Cc: list to see if they have
> comments on how many IRQs are needed.

The bits in question is really the number of possible nested interrupts 
that can happen. We take the paranoid approach that we can have a max 
nesting of NR_IRQS. Perhaps this can be changed, and just do a max of 
1<<10 nesting? And have a big warn on if it happens to be bigger, or fall 
to another counter if it is bigger.

1000 nested IRQs seems a bit extreme :-/

Just throwing out some ideas.

-- Steve

--
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/