[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090421102402.GZ14687@one.firstfloor.org>
Date: Tue, 21 Apr 2009 12:24:02 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Tim Abbott <tabbott@....EDU>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
Anders Kaseorg <andersk@....EDU>,
Waseem Daher <wdaher@....EDU>,
Denys Vlasenko <vda.linux@...glemail.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Andi Kleen <andi@...stfloor.org>,
"H. Peter Anvin" <hpa@...or.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Jeff Arnold <jbarnold@....EDU>,
Andrew Morton <akpm@...ux-foundation.org>,
Jon Masters <jonathan@...masters.org>
Subject: Re: [PATCH v2 0/4] Add support for compiling with -ffunction-sections -fdata-sections
> Are there any advantages outside of the size things?
Yes ksplice needs it too.
> Do we end up packing data better?
There used to be tools to do that (use profile feedback to pack
code), but I'm not sure they would help the kernel too much
because they were mostly aimed at demand paging. But such tools
definitely would need this infrastructure. Iirc there are some architectures
othat benefit from hold/cold partioning during execution.
> I'd like to have some more champions of this code, in other words.
I definitely like the size angle -- letting the linker eliminate
code without ifdef jungles certainly sounds attractive to me.
Also if we find broken toolchains I suppose it wouldn't be too
difficult to black list them.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
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