Messages in this thread | | | Subject | RE: [PATCH][RFC] make cpu_sibling_map a cpumask_t | Date | Mon, 8 Dec 2003 20:54:31 -0800 | From | "Nakajima, Jun" <> |
| |
> > 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |