This is from an earlier message from 'Christoph Lameter':
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpu.
If we put the cpu_core_map into the per cpu area then it will be allocated
fo
This is from an earlier message from 'Christoph Lameter':
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpu.
If we put the cpu_core_map into the per cpu area then it will be allocated
fo
This is from an earlier message from 'Christoph Lameter':
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpu.
If we put the cpu_core_map into the per cpu area then it will be allocated
fo
On Tue, 17 Jul 2007 12:27:18 -0700
"Siddha, Suresh B" <[EMAIL PROTECTED]> wrote:
> Is there a reason why cpu_sibling_map[] is left out in these changes?
Yes this patch is a trial balloon to make sure that I/we do the right
thing when dealing with the other cpu maps. Patchset will hopefully
soon
On Thu, Jul 12, 2007 at 11:58:06PM -0700, Christoph Lameter wrote:
> cpu_core_map is currently an array defined using NR_CPUS. This means that
> we overallocate since we will rarely really use the maximum
> number of configured cpus. This may become a problem when we need to
> increase the NR_CPU
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 13 Jul 2007 15:50:33 -0700 (PDT)
> Core cpu and node maps exist in the page allocator and are defined in
> nodemask.h and cpumask.h. I have recently introduced a framework that
> allows the definition of new masks that could be used in the f
On Fri, 13 Jul 2007, David Miller wrote:
> I see, the acessor is abstracted via a function.
Yes. The accessor for the scheduler is defined for each arch in topology.c
> That seems pointless, and allows you to do things like this, improving
> the implementation on one set of platforms yet leave
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Fri, 13 Jul 2007 09:34:02 -0700 (PDT)
> But the code modified here is x86_64 and i386 specific? Is there an
> overlap?
I see, the acessor is abstracted via a function.
That seems pointless, and allows you to do things like this, improving
the im
On Fri, 13 Jul 2007, David Miller wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Thu, 12 Jul 2007 23:58:06 -0700 (PDT)
>
> > cpu_core_map is currently an array defined using NR_CPUS. This means that
> > we overallocate since we will rarely really use the maximum
> > number of confi
Christoph Lameter wrote:
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use the maximum
number of configured cpus. This may become a problem when we need to
increase the NR_CPUs on x86_64 for our new product line.
If we pu
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 12 Jul 2007 23:58:06 -0700 (PDT)
> cpu_core_map is currently an array defined using NR_CPUS. This means that
> we overallocate since we will rarely really use the maximum
> number of configured cpus. This may become a problem when we need to
cpu_core_map is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use the maximum
number of configured cpus. This may become a problem when we need to
increase the NR_CPUs on x86_64 for our new product line.
If we put the cpu_core_map into the
12 matches
Mail list logo
