[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081117125317.GK6703@one.firstfloor.org>
Date: Mon, 17 Nov 2008 13:53:17 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Alexander van Heukelum <heukelum@...tmail.fm>
Cc: Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>,
Alexander van Heukelum <heukelum@...i.uni-sb.de>,
Glauber Costa <gcosta@...hat.com>
Subject: Re: [RFC] x86: save_args out of line
On Sun, Nov 16, 2008 at 03:29:01PM +0100, Alexander van Heukelum wrote:
> From: Alexander van Heukelum <heukelum@...ipnir.lusi.uni-sb.de>
>
> The macro "interrupt" in entry_64.S generates a lot of code. This
> patch moves most of its contents into an external function. It
> saves anywhere between 500 and 2500 bytes of text depending on the
> configuration.
The only duplication is in the apicinterrupt entry points which
have expanded recently (when I wrote all that there weren't as many)
I think it would be cleaner to just have a common apic_interrupt
entry point similar to how the exceptions work that try to factor
out "interrupt" like this. As more and more of them get added
(I have another new one in recent) patches that will likely
save more space.
The only ugly part is that passing the handler to the common
stub requires the manual pt_regs setup that the exception
handler currently does. Because that could be factored
out in a new macro. Or just copied (I have heard complaints
in the past that the file has too many macros already)
> There is a comment in the original code about saving rbp twice, but
> I don't understand what the code tries to do. First of all, the
To be honest I didn't understand this one either when it was added. In
standard frame pointer format rbp has to be at the place pointed to by the real
rbp register with the return address directly on top of it. But pushing
%rbp below the pt_regs doesn't put it into this format, because
the return address is at the wrong place.
-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