linux-kernel - Re: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it

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, 2 Aug 2013 22:30:53 -0700
From:	Olof Johansson <olof@...om.net>
To:	Matt Sealey <neko@...uhatsu.net>
Cc:	Tony Lindgren <tony@...mide.com>,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat
 and how to avoid it

On Fri, Aug 2, 2013 at 2:31 PM, Matt Sealey <neko@...uhatsu.net> wrote:
> On Fri, Aug 2, 2013 at 3:13 AM, Tony Lindgren <tony@...mide.com> wrote:
>> * Mel Gorman <mgorman@...e.de> [130731 08:28]:
>>> On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote:
>>> > Hi all,
>>> >
>>> > Probably the biggest kernel data bloat issue is in the ARM land, but
>>> > it also seems that it's becoming a Linux generic issue too, so I
>>> > guess it could be discussed in either context.
>>> >
>>>
>>> Would scripts/bloat-o-meter highlight where the growth problems are?
>>
>> Well to some extent yes, the board/SoC/driver specific options are
>> often behind Kconfig options. So if you want to limit the set of
>> supported SoCs and drivers for the kernel you can optimize it out.
>>
>> The bloat-o-meter won't help for things like checking that a device
>> tree binding really describes the hardware, and is not just pointing
>> to a table of defined registers in the device driver.
>
> Specifically naming and shaming, like arch/arm/mach-imx/clk-*.c kind

[...]

TL;DR. Some friendly advice is to reduce the verbosity of your emails.
I lost patience a couple of paragraphs in.

I think we could come a long way on this if we could sort out probe
and init order enough that we could modularize some of this data (and
init code). I.e. if you could load some of these tables and drivers as
modules a lot of the bloat would no longer be an issue.

The problem, of course, is that things like clock, pinmux, etc tables
(and drivers) tend to be needed very early during boot and thus can
definitely not wait to the point where we usually run ramdisk
contents.

We could mandate that whatever drivers are needed on top also be
modules, which would take care of some of the dependency chain, but we
don't have a great way today to describe the needed probe/load order
of said modules. So it'd still need some new and additional
functionality to work well.

Pushing everything out into modules will also add some complexity for
embedded platforms who rather avoid ramdisks, and it will likely add
boot time which matters a lot to some users. On the other hand, it's
less likely to matter to the users who at the same time care about the
bloat of a multiplatform kernel, i.e. you tend to ether optimize for
boot time on particular well-defined hardware, or you care more about
having something that boots on most hardware but possibly with some
overhead in boot performance.

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