linux-kernel - Re: 2.6.18-mm2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Sep 2006 22:58:24 +0200
From:	Andi Kleen <ak@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jim Cromie <jim.cromie@...il.com>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.18-mm2

On Friday 29 September 2006 22:32, Ingo Molnar wrote:
> 
> * Andi Kleen <ak@...e.de> wrote:
> 
> > On Friday 29 September 2006 22:14, Ingo Molnar wrote:
> > > 
> > > * Andi Kleen <ak@...e.de> wrote:
> > > 
> > > > BTW I was planning to make LOCAL_APIC unconditional on i386 too like 
> > > > on x86-64.
> > > 
> > > please dont - embedded doesnt need it most of the time.
> > 
> > What do you mean with not need?  Local APIC is an infinitely better 
> > interface than PIC and faster. On embedded too this makes a lot of 
> > sense.
> 
> it's just not present or hardware-disabled.

The kernel won't use it then. Also on next years embedded systems
this will likely change.

> 
> > And a lot of modern systems don't even work anymore without APIC 
> > enabled because Windows uses it and the BIOS haven't been tested 
> > without it (e.g. you often find totally broken code paths in the AML 
> > for PIC mode)
> > 
> > The code size also isn't a good argument because the delta
> > isn't that big:
> > 
> >    text    data     bss     dec     hex filename
> > 3303894  694980  436420 4435294  43ad5e obj32-up/vmlinux
> > 3266532  665732  402372 4334636  42242c obj32-up-noapic/vmlinux
> > 
> > ~63K.
> 
> 63K???? You've got to be kidding. That's huge. That's ~10% of the 
> minconfig kernel. 

A large part of it is the ACPI support. Without that it's smaller:

   text    data     bss     dec     hex filename
2978333  640752  416100 4035185  3d9271 obj32-up-noacpi/vmlinux
2947808  612088  400292 3960188  3c6d7c obj32-up-noacpi-noapic/vmlinux

~30k

You might be able to do without ACPI on your embedded system.

> Even 1K would be bad. We did config hacks for half a K  
> win. 

<rant>

Sorry, but that's silly. I did some measurements and just tweaking a 
few dynamic allocation pigs saves you much more memory without 
uglifying the code. In fact in most configurations you can find dynamic 
users who need more than the complete kernel text - this means 
even if you got the kernel text down to 0 bytes you wouldn't save as 
much as simple tweaks in the dynamic pig.

I know it's easy to do size vmlinux and complain about bloat there, 
but that is really not where the real bloat is. Finding the 
real ones takes more effort of course.

And maintainability is much more important. Too many CONFIGs
just waste developer time and this one is particularly nasty
because it tends to break all the time.

And if you really want to make vmlinux smaller anyways you usually
get much better payoff by concentrating on inline functions than
uglifying the code with more CONFIGs. A few people did excellent
work on that recently and the kernel actually shrunk for most people, not
just some extreme config. But CONFIGs just 
cause everybody more work for usually very little payoff.

</rant>

-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/