From: greg@kroah.com (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it
Date: Fri, 2 Aug 2013 16:11:03 +0800 [thread overview]
Message-ID: <20130802081103.GA3042@kroah.com> (raw)
In-Reply-To: <20130802075352.GY7656@atomide.com>
On Fri, Aug 02, 2013 at 12:53:53AM -0700, Tony Lindgren wrote:
> * Greg KH <greg@kroah.com> [130731 05:39]:
> > 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.
> >
> > Why is it specific to ARM? What is so unique to ARM that causes it to
> > "bloat"?
>
> I think it has so far showed up on ARM because of no discoverable busses,
> but chances are it will be more of a generic problem.
>
> > And what exactly do you mean by "bloat"?
>
> Stuffing data to kernel that should not be in the kernel at all. Or
> if the data is needed by kernel, there should be only one set of the
> data defined rather than multiple copies of the data built into the
> kernel for each SoC or driver variant.
>
> > > Basically the data bloat issue is there for the arch code and drivers
> > > and may not show up initially until things have headed the wrong way for
> > > too long.
> >
> > What do you mean by this? You seem to be very vague here.
>
> People are unnecessarily defining registers in kernel for similar devices
> over and over again for each new SoC at the arch level and now more and
> more at the driver level.
>
> One example of that are device tree based drivers that don't describe
> the actual hardware, but instead have a binding that points to an index
> of defined registers in the driver.
Ok, and exactly how much "larger" does something like this cost as a
real number, and as a percentage of the size of the kernel?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Tony Lindgren <tony@atomide.com>
Cc: ksummit-2013-discuss@lists.linuxfoundation.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it
Date: Fri, 2 Aug 2013 16:11:03 +0800 [thread overview]
Message-ID: <20130802081103.GA3042@kroah.com> (raw)
In-Reply-To: <20130802075352.GY7656@atomide.com>
On Fri, Aug 02, 2013 at 12:53:53AM -0700, Tony Lindgren wrote:
> * Greg KH <greg@kroah.com> [130731 05:39]:
> > 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.
> >
> > Why is it specific to ARM? What is so unique to ARM that causes it to
> > "bloat"?
>
> I think it has so far showed up on ARM because of no discoverable busses,
> but chances are it will be more of a generic problem.
>
> > And what exactly do you mean by "bloat"?
>
> Stuffing data to kernel that should not be in the kernel at all. Or
> if the data is needed by kernel, there should be only one set of the
> data defined rather than multiple copies of the data built into the
> kernel for each SoC or driver variant.
>
> > > Basically the data bloat issue is there for the arch code and drivers
> > > and may not show up initially until things have headed the wrong way for
> > > too long.
> >
> > What do you mean by this? You seem to be very vague here.
>
> People are unnecessarily defining registers in kernel for similar devices
> over and over again for each new SoC at the arch level and now more and
> more at the driver level.
>
> One example of that are device tree based drivers that don't describe
> the actual hardware, but instead have a binding that points to an index
> of defined registers in the driver.
Ok, and exactly how much "larger" does something like this cost as a
real number, and as a percentage of the size of the kernel?
thanks,
greg k-h
next prev parent reply other threads:[~2013-08-02 8:11 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 7:38 [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it Tony Lindgren
2013-07-31 7:38 ` Tony Lindgren
2013-07-31 12:33 ` [Ksummit-2013-discuss] " Greg KH
2013-07-31 12:33 ` Greg KH
2013-07-31 13:53 ` Jason Cooper
2013-07-31 13:53 ` Jason Cooper
2013-08-02 7:55 ` Tony Lindgren
2013-08-02 7:55 ` Tony Lindgren
2013-08-02 7:53 ` Tony Lindgren
2013-08-02 7:53 ` Tony Lindgren
2013-08-02 8:03 ` Felipe Balbi
2013-08-02 8:03 ` Felipe Balbi
2013-08-02 8:26 ` Tony Lindgren
2013-08-02 8:26 ` Tony Lindgren
2013-08-02 8:11 ` Greg KH [this message]
2013-08-02 8:11 ` Greg KH
2013-08-02 8:39 ` Tony Lindgren
2013-08-02 8:39 ` Tony Lindgren
2013-08-02 12:41 ` Tony Lindgren
2013-08-02 12:41 ` Tony Lindgren
2013-08-02 13:24 ` Russell King - ARM Linux
2013-08-02 13:24 ` Russell King - ARM Linux
2013-08-05 6:30 ` Tony Lindgren
2013-08-05 6:30 ` Tony Lindgren
2013-08-02 19:57 ` Mike Turquette
2013-08-02 19:57 ` Mike Turquette
2013-08-05 6:36 ` Tony Lindgren
2013-08-05 6:36 ` Tony Lindgren
2013-07-31 15:21 ` Mel Gorman
2013-07-31 15:21 ` Mel Gorman
2013-08-02 8:13 ` Tony Lindgren
2013-08-02 8:13 ` Tony Lindgren
2013-08-02 21:31 ` Matt Sealey
2013-08-02 21:31 ` Matt Sealey
2013-08-03 5:30 ` Olof Johansson
2013-08-03 5:30 ` Olof Johansson
2013-08-05 6:43 ` Tony Lindgren
2013-08-05 6:43 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130802081103.GA3042@kroah.com \
--to=greg@kroah.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.