[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081104203046.GF29626@one.firstfloor.org>
Date: Tue, 4 Nov 2008 21:30:46 +0100
From: Andi Kleen <andi@...stfloor.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Alexander van Heukelum <heukelum@...tmail.fm>,
Andi Kleen <andi@...stfloor.org>,
Cyrill Gorcunov <gorcunov@...il.com>,
Alexander van Heukelum <heukelum@...lshack.com>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>, lguest@...abs.org,
jeremy@...source.com, Steven Rostedt <srostedt@...hat.com>,
Mike Travis <travis@....com>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
> Fixing the first of these I think is a no-brainer. That will cut the
> size of the existing stub pool by almost half. The second is more of a
> judgement call, and I'd like to see performance numbers for it. Either
> which way, I think it's worthwhile to consider this as an alternative to
> playing segmentation tricks, which I think could have really nasty
> side effects.
Or again just generate them on demand when the interrupt is set up.
If you really have 240 interrupts sources you can afford the 5k likely,
but for most there will be only a minimum number of stubs.
Although frankly I suspect there are far easier ways to save 5k of memory.
-Andi
--
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