RE: [PATCH][RFC] make cpu_sibling_map a cpumask_t

Nakajima, Jun
2003-12-09T04:54:40Z

> > It turns the cpu_sibling_map array from an array of cpus to an array
> > of cpumasks. This allows handling of more than 2 siblings, not that
> > I know of any immediate need.
We need this sooner or later.

Jun
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Zwane Mwaikambo
> Sent: Monday, December 08, 2003 12:51 PM
> To: Nick Piggin
> Cc: Ingo Molnar; Anton Blanchard; Linus Torvalds; Andrew Morton; Rusty
> Russell; linux-kernel
> Subject: Re: [PATCH][RFC] make cpu_sibling_map a cpumask_t
>
> On Mon, 8 Dec 2003, Nick Piggin wrote:
>
> > It turns the cpu_sibling_map array from an array of cpus to an array
> > of cpumasks. This allows handling of more than 2 siblings, not that
> > I know of any immediate need.
> >
> > I think it generalises cpu_sibling_map sufficiently that it can
become
> > generic code. This would allow architecture specific code to build
the
> > sibling map, and then Ingo's or my HT implementations to build their
> > scheduling descriptions in generic code.
> >
> > I'm not aware of any reason why the kernel should not become
generally
> > SMT aware. It is sufficiently different to SMP that it is worth
> > specialising it, although I am only aware of P4 and POWER5
> implementations.
>
> Generally i agree, it's fairly unintrusive and appears to clean up
some
> things. Perhaps Andrew will take it a bit later after release.
>
> > P.S.
> > I have an alternative to Ingo's HT scheduler which basically does
> > the same thing. It is showing a 20% elapsed time improvement with a
> > make -j3 on a 2xP4 Xeon (4 logical CPUs).
>
> -j3 is an odd number, what does -j4, -j8, -j16 look like?