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]
Message-Id: <1189186690.7636.12.camel@imap.mvista.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ