On Sat, 25 Aug 2007, Andi Kleen wrote:
> On Fri, Aug 24, 2007 at 05:50:18PM -0700, Siddha, Suresh B wrote:
> > On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
> > > Previous Intro:
> >
> > Thanks for doing this.
> >
> > > In x86_64 and i386 architectures most arrays that are
On Sat, 25 Aug 2007, Andi Kleen wrote:
On Fri, Aug 24, 2007 at 05:50:18PM -0700, Siddha, Suresh B wrote:
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
Previous Intro:
Thanks for doing this.
In x86_64 and i386 architectures most arrays that are sized
using
On Sat, 25 Aug 2007 11:24:35 +0200 Andi Kleen wrote:
> On Fri, Aug 24, 2007 at 05:50:18PM -0700, Siddha, Suresh B wrote:
> > On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
> > > Previous Intro:
> >
> > Thanks for doing this.
> >
> > > In x86_64 and i386 architectures most
On Fri, Aug 24, 2007 at 05:50:18PM -0700, Siddha, Suresh B wrote:
> On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
> > Previous Intro:
>
> Thanks for doing this.
>
> > In x86_64 and i386 architectures most arrays that are sized
> > using NR_CPUS lay in local memory on node 0.
On Fri, Aug 24, 2007 at 05:50:18PM -0700, Siddha, Suresh B wrote:
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
Previous Intro:
Thanks for doing this.
In x86_64 and i386 architectures most arrays that are sized
using NR_CPUS lay in local memory on node 0. Not only
On Sat, 25 Aug 2007 11:24:35 +0200 Andi Kleen wrote:
On Fri, Aug 24, 2007 at 05:50:18PM -0700, Siddha, Suresh B wrote:
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
Previous Intro:
Thanks for doing this.
In x86_64 and i386 architectures most arrays that are
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
> Previous Intro:
Thanks for doing this.
> In x86_64 and i386 architectures most arrays that are sized
> using NR_CPUS lay in local memory on node 0. Not only will most
> (99%?) of the systems not use all the slots in these
Changes for version v2:
> > Note the addtional change of the cpu_llc_id type from u8
> > to int for ARCH x86_64 to correspond with ARCH i386.
> At least currently it cannot be more than 8 bit. So why
> waste memory? It would be better to change i386
Done. (x86_64 type => u8).
> > Fix four
Changes for version v2:
Note the addtional change of the cpu_llc_id type from u8
to int for ARCH x86_64 to correspond with ARCH i386.
At least currently it cannot be more than 8 bit. So why
waste memory? It would be better to change i386
Done. (x86_64 type = u8).
Fix four instances
On Fri, Aug 24, 2007 at 03:26:54PM -0700, [EMAIL PROTECTED] wrote:
Previous Intro:
Thanks for doing this.
In x86_64 and i386 architectures most arrays that are sized
using NR_CPUS lay in local memory on node 0. Not only will most
(99%?) of the systems not use all the slots in these arrays,
10 matches
Mail list logo