It bugs me that we're evaluating the same thing down in arch/i386/Makefile. Perhaps we should evaluate GCC_VERSION once only, as some top-level kbuild thing. So everyone can assume that it's present and correct? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> With all alignment options set to 1 (minimum alignment), > I've got 5% smaller vmlinux compared to one built with > default code alignment.
It would be interesting to know if this is better WRT cache usage than alignment which ensures that loops fit within the minimum number of cache lines. That's not quite the same thing as starting on a cache line in all cases.
This may be of interest to embedded builds.
-- -bill davidsen (david...@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
>It bugs me that we're evaluating the same thing down in arch/i386/Makefile. > Perhaps we should evaluate GCC_VERSION once only, as some top-level kbuild >thing. So everyone can assume that it's present and correct?
Using '=' is wrong here, it will evaluate the complete expression every time GCC_VERSION is tested. It should be ':='. The only time '=' should be used in a Makefile is when delayed evaluation is really required, e.g. for strings that are the target of $(call).
> With all alignment options set to 1 (minimum alignment), > I've got 5% smaller vmlinux compared to one built with > default code alignment.
> Rediffed against 2.6.9-rc3. > Please apply.
I agree with the basic idea (the big alignments also always annoy me when I look at disassembly), but I think your CONFIG options are far too complicated. I don't think anybody will go as far as to tune loops vs function calls.
I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to 1, that should be enough.
> > With all alignment options set to 1 (minimum alignment), > > I've got 5% smaller vmlinux compared to one built with > > default code alignment.
> > Rediffed against 2.6.9-rc3. > > Please apply.
> I agree with the basic idea (the big alignments also always annoy > me when I look at disassembly), but I think your CONFIG options > are far too complicated. I don't think anybody will go as far as > to tune loops vs function calls.
> I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to > 1, that should be enough.
For me, yes, but there are people which are slightly less obsessed with code size than me.
They might want to say "try to align to 16 bytes if it costs less than 5 bytes" etc.
Also bencmarking people may do little research on real usefulness of various kinds of alignment. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Fri, 8 Oct 2004, Denis Vlasenko wrote: > On Friday 08 October 2004 12:20, Andi Kleen wrote: >> Denis Vlasenko <v...@port.imtp.ilyichevsk.odessa.ua> writes: >>> Resend.
>>> With all alignment options set to 1 (minimum alignment), >>> I've got 5% smaller vmlinux compared to one built with >>> default code alignment.
>>> Rediffed against 2.6.9-rc3. >>> Please apply.
>> I agree with the basic idea (the big alignments also always annoy >> me when I look at disassembly), but I think your CONFIG options >> are far too complicated. I don't think anybody will go as far as >> to tune loops vs function calls.
>> I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to >> 1, that should be enough.
> For me, yes, but there are people which are slightly less obsessed > with code size than me.
> They might want to say "try to align to 16 bytes if > it costs less than 5 bytes" etc.
> Also bencmarking people may do little research on real usefulness of > various kinds of alignment.
I think that removing aligns completly will be very bad. I am Gentoo user and I set my user space CFLAGS for all system to -falign-loops -fno-align-<everything else>. I did not tested it in depth, but my simple tests show that unaligning loops is a very bad idea. Unaligning functions is safer since small and fast functions should be always inlined.
On Fri, Oct 08, 2004 at 05:10:58PM +0000, Denis Vlasenko wrote: > On Friday 08 October 2004 12:20, Andi Kleen wrote: > > Denis Vlasenko <v...@port.imtp.ilyichevsk.odessa.ua> writes: > > > Resend.
> > > With all alignment options set to 1 (minimum alignment), > > > I've got 5% smaller vmlinux compared to one built with > > > default code alignment.
> > I agree with the basic idea (the big alignments also always annoy > > me when I look at disassembly), but I think your CONFIG options > > are far too complicated. I don't think anybody will go as far as > > to tune loops vs function calls.
> > I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to > > 1, that should be enough.
> For me, yes, but there are people which are slightly less obsessed > with code size than me.
> They might want to say "try to align to 16 bytes if > it costs less than 5 bytes" etc.
If they want to go down to that low level they can as well edit the Makefiles. But we already have far too many configs and adding new ones for obscure compiler options is not a good idea.
Also we don't normally add stuff "just in case", but only when people actually use it.
On Friday 08 October 2004 17:30, Grzegorz Kulewski wrote:
> > Also bencmarking people may do little research on real usefulness of > > various kinds of alignment.
> I think that removing aligns completly will be very bad. I am Gentoo user > and I set my user space CFLAGS for all system to -falign-loops > -fno-align-<everything else>. I did not tested it in depth, but my simple > tests show that unaligning loops is a very bad idea. Unaligning functions
That depends on how often that loop runs. 90% of code runs only 10% of time. I think ultimately we want to mark other 10% of code with:
int __hotpath often_called_func() { ...
}
Rest of code is to be optimized for size.
> is safer since small and fast functions should be always inlined.
Concept of alignment does not apply to inlined functions at all. -- vda
> > > I would just do a single CONFIG_NO_ALIGNMENTS that sets everything to > > > 1, that should be enough.
> > For me, yes, but there are people which are slightly less obsessed > > with code size than me.
> > They might want to say "try to align to 16 bytes if > > it costs less than 5 bytes" etc.
> If they want to go down to that low level they can as well edit > the Makefiles. But we already have far too many configs and > adding new ones for obscure compiler options is not a good idea.
> Also we don't normally add stuff "just in case", but only when > people actually use it.
I have a suspicion that if I had submitted CONFIG_NO_ALIGNMENTS patch instead, there would be comments from another crowd, about it being too coarse.
Look at the post of Grzegorz Kulewski.
Anyway, I don't have strong preference. I just want to be at least able to disable code alignment completely. -- vda
On Fri, 8 Oct 2004, Denis Vlasenko wrote: > On Friday 08 October 2004 17:30, Grzegorz Kulewski wrote: >>> Also bencmarking people may do little research on real usefulness of >>> various kinds of alignment.
>> I think that removing aligns completly will be very bad. I am Gentoo user >> and I set my user space CFLAGS for all system to -falign-loops >> -fno-align-<everything else>. I did not tested it in depth, but my simple >> tests show that unaligning loops is a very bad idea. Unaligning functions
> That depends on how often that loop runs. 90% of code runs only > 10% of time. I think ultimately we want to mark other 10% of code with:
Well, loops should probably always be aligned because aligning them will not make the code significantly larger (I think, I did not mensure it), but it will make the code significantly faster, and more friendly to processor's cache.
>> is safer since small and fast functions should be always inlined.
> Concept of alignment does not apply to inlined functions at all.
That is my point. It is safe not to align functions because fast and often called ones will be inlined and will not be slowed down by lack of alignment.
> It bugs me that we're evaluating the same thing down in arch/i386/Makefile. > Perhaps we should evaluate GCC_VERSION once only, as some top-level kbuild > thing. So everyone can assume that it's present and correct?
Started looking into this. gcc does not document what happens if -falign-functions=x is specified more than once. It works but I have not checked the effect. It will occur for some CPU's
Sam
Current patch to top-level Makefile looks like this.
ifdef CONFIG_FRAME_POINTER CFLAGS += -fno-omit-frame-pointer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
