All of lore.kernel.org
 help / color / mirror / Atom feed
From: peterz@infradead.org (Peter Zijlstra)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 3/4] ARM: topology: Update cpu_power according to DT information
Date: Wed, 13 Jun 2012 18:06:48 +0200	[thread overview]
Message-ID: <1339603608.8980.55.camel@twins> (raw)
In-Reply-To: <CAKfTPtDkRZJmfwmOeR6TPc5etbWRRneWAmN13X2_ace4wFwf7A@mail.gmail.com>

On Wed, 2012-06-13 at 16:54 +0200, Vincent Guittot wrote:
> On 13 June 2012 15:07, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> >> +struct cpu_capacity cpu_capacity[NR_CPUS];
> >
> > I know ARM isn't likely to suffer from the 4k cpu issue, but is there a
> > reason to use a NR_CPUS array over a per-cpu variable?
> 
> At this stage, we don't know which logical CPU will match which hwid.
> During the boot of each CPU, we parse the table to found an efficiency
> value for the booting CPU. The whole table is used by one CPU at a
> time.

Its not so much the usage as the dynamic sizing that I was after.
NR_CPUS will always be the max size, whereas per-cpu data will only use
the amount of storage required to back the number of cpus present.

For this reason we've spend a great deal of effort to remove NR_CPUS
sized arrays all over the core (and x86/ia64 arch) code, since distros
now build with NR_CPUS=4096 but hardly anybody has that many cpus, so
arrays sized that way waste tons of resources.

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org,
	devicetree-discuss@lists.ozlabs.org, linux@arm.linux.org.uk,
	grant.likely@secretlab.ca, rob.herring@calxeda.com
Subject: Re: [RFC 3/4] ARM: topology: Update cpu_power according to DT information
Date: Wed, 13 Jun 2012 18:06:48 +0200	[thread overview]
Message-ID: <1339603608.8980.55.camel@twins> (raw)
In-Reply-To: <CAKfTPtDkRZJmfwmOeR6TPc5etbWRRneWAmN13X2_ace4wFwf7A@mail.gmail.com>

On Wed, 2012-06-13 at 16:54 +0200, Vincent Guittot wrote:
> On 13 June 2012 15:07, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote:
> >> +struct cpu_capacity cpu_capacity[NR_CPUS];
> >
> > I know ARM isn't likely to suffer from the 4k cpu issue, but is there a
> > reason to use a NR_CPUS array over a per-cpu variable?
> 
> At this stage, we don't know which logical CPU will match which hwid.
> During the boot of each CPU, we parse the table to found an efficiency
> value for the booting CPU. The whole table is used by one CPU at a
> time.

Its not so much the usage as the dynamic sizing that I was after.
NR_CPUS will always be the max size, whereas per-cpu data will only use
the amount of storage required to back the number of cpus present.

For this reason we've spend a great deal of effort to remove NR_CPUS
sized arrays all over the core (and x86/ia64 arch) code, since distros
now build with NR_CPUS=4096 but hardly anybody has that many cpus, so
arrays sized that way waste tons of resources.

  reply	other threads:[~2012-06-13 16:06 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-12 12:02 [RFC 0/4] ARM: topology: set the capacity of each cores for big.LITTLE Vincent Guittot
2012-06-12 12:02 ` Vincent Guittot
2012-06-12 12:02 ` [RFC 1/4] ARM: topology: Add arch_scale_freq_power function Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-13  8:50   ` Jean Pihet
2012-06-13  8:50     ` Jean Pihet
2012-06-13  9:22     ` Vincent Guittot
2012-06-13  9:22       ` Vincent Guittot
2012-06-13 12:52   ` Peter Zijlstra
2012-06-13 12:52     ` Peter Zijlstra
2012-06-13 19:27     ` Andy Whitcroft
2012-06-13 19:27       ` Andy Whitcroft
2012-06-13 19:27       ` Andy Whitcroft
2012-06-13 19:30       ` Joe Perches
2012-06-13 19:30         ` Joe Perches
2012-06-13 21:51       ` Peter Zijlstra
2012-06-13 21:51         ` Peter Zijlstra
2012-06-12 12:02 ` [RFC 2/4] ARM: topology: factorize the update of sibling masks Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-13 12:54   ` Peter Zijlstra
2012-06-13 12:54     ` Peter Zijlstra
2012-06-12 12:02 ` [RFC 3/4] ARM: topology: Update cpu_power according to DT information Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-13  8:59   ` Jean Pihet
2012-06-13  8:59     ` Jean Pihet
2012-06-13  9:44     ` Vincent Guittot
2012-06-13  9:44       ` Vincent Guittot
2012-06-13 12:44       ` Amit Kucheria
2012-06-13 12:44         ` Amit Kucheria
2012-06-13 12:47         ` Peter Zijlstra
2012-06-13 12:47           ` Peter Zijlstra
2012-06-13 12:50           ` Jean Pihet
2012-06-13 12:50             ` Jean Pihet
2012-06-13 13:29           ` Vincent Guittot
2012-06-13 13:29             ` Vincent Guittot
2012-06-13 13:32             ` Peter Zijlstra
2012-06-13 13:32               ` Peter Zijlstra
2012-06-13 14:31               ` Vincent Guittot
2012-06-13 14:31                 ` Vincent Guittot
2012-06-13 13:07   ` Peter Zijlstra
2012-06-13 13:07     ` Peter Zijlstra
2012-06-13 14:54     ` Vincent Guittot
2012-06-13 14:54       ` Vincent Guittot
2012-06-13 16:06       ` Peter Zijlstra [this message]
2012-06-13 16:06         ` Peter Zijlstra
2012-06-13 13:09   ` Peter Zijlstra
2012-06-13 13:09     ` Peter Zijlstra
2012-06-13 14:42     ` Nicolas Pitre
2012-06-13 14:42       ` Nicolas Pitre
2012-06-13 13:19   ` Peter Zijlstra
2012-06-13 13:19     ` Peter Zijlstra
2012-06-13 13:19     ` Peter Zijlstra
2012-06-12 12:02 ` [RFC 4/4] sched: cpu_power: enable ARCH_POWER Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-12 12:02   ` Vincent Guittot
2012-06-13 12:50   ` Peter Zijlstra
2012-06-13 12:50     ` Peter Zijlstra
2012-06-13 13:20     ` Vincent Guittot
2012-06-13 13:20       ` Vincent Guittot
2012-06-13 13:20       ` Vincent Guittot
2012-06-13 13:28       ` Peter Zijlstra
2012-06-13 13:28         ` Peter Zijlstra
2012-06-13 13:50         ` Vincent Guittot
2012-06-13 13:50           ` Vincent Guittot
2012-06-20 10:43         ` [tip:sched/core] sched/x86: Remove broken power estimation tip-bot for Peter Zijlstra
2012-07-24 14:13         ` tip-bot for Peter Zijlstra

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=1339603608.8980.55.camel@twins \
    --to=peterz@infradead.org \
    --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.