[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130802081315.GA7656@atomide.com>
Date: Fri, 2 Aug 2013 01:13:15 -0700
From: Tony Lindgren <tony@...mide.com>
To: Mel Gorman <mgorman@...e.de>
Cc: ksummit-2013-discuss@...ts.linuxfoundation.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat
and how to avoid it
* 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.
A lot of the board specific, SoC specific, driver specific, debug
specifc and so on "data" should not be in the kernel to start with
and we can provide the same level of supported features in the kernel.
Regards,
Tony
--
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