linux-kernel - Re: [PATCH 0/3] build system: section garbage collection for vmlinux

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 07 Sep 2007 10:38:09 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	sam@...nborg.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] build system: section garbage collection for
	vmlinux

On Fri, 2007-09-07 at 18:30 +0100, Denys Vlasenko wrote:
> On Friday 07 September 2007 17:31, Daniel Walker wrote:
> > On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote:
> > > A bit extended version:
> > > 
> > > In the process in making it work I saw ~10% vmlinux size reductions
> > > (which basically matches what Marcelo says) when I wasn't retaining
> > > sections needed for EXPORT_SYMBOLs, but module loading didn't work.
> > > 
> > > Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs
> > > are never discarded. This was just one of many fixes until kernel
> > > started to actually boot and work.
> > > 
> > > I did that before I posted patches to lkml.
> > > IOW: posted patches are not broken versus module loading.
> > 
> > Ok, this is more like the explanation I was looking for..
> > 
> > During this thread you seemed to indicate the patches you release
> > reduced the kernel ~10% , but now your saying that was pre-release ,
> > right?
> 
> CONFIG_MODULE=n will save ~10%
> CONFIG_MODULE=y - ~1%
> 
> Exact figure depends on .config (whether you happen to include
> especially "fat" code or not).
> 
> I want to explain a bit where I am coming from. I am working on busybox,
> and last release made busybox smaller by "whopping" 2%. This is the result
> of a hundred or so of small code and data shrinks.
> 
> It basically means that I am close to the point of diminishing returns
> trying to make busybox smaller, and memory wastage on the running
> embedded system is now elsewhere - including kernel.

I think this type of pruning is a good thing, you could even say the
biggest bit of low hanging fruit in terms of size reduction. 

I think your patches are good, but need some work. There are still some
changes that could reduce the kernel further (i.e. when modules are
used) .. So I'm not trying to discourage you, but you set off some
alarms with me early in the thread.. Which caused this to drag out..

Daniel

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