[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57C9024A16AD2D4C97DC78E552063EA361689CF0@orsmsx505.amr.corp.intel.com>
Date: Wed, 11 Feb 2009 10:34:39 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Steven Rostedt <rostedt@...dmis.org>
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
> 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 :-/
Ah, I see. Then the answer is very different. The number of nested
interrupts possible on a cpu is limited by the number of priority
classes for interrupts (See Table 5-8 on page 2:112 of the Itanium
software developers manual). Effectively the max nesting depth is
16.
1000 nested interrupts would be certain to run us out of stack.
-Tony
--
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