* Re: [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 [not found] <200812011646.35018.rusty@rustcorp.com.au> @ 2008-12-17 22:54 ` Mike Travis 2008-12-17 23:02 ` Mike Travis 2008-12-18 6:14 ` Rusty Russell 0 siblings, 2 replies; 3+ messages in thread From: Mike Travis @ 2008-12-17 22:54 UTC (permalink / raw) To: Rusty Russell Cc: Ingo Molnar, Stephen Rothwell, LKML, linux-next, Jack Steiner Rusty Russell wrote: > Like cpu_coregroup_map, but returns a (const) pointer. > > (This will go to Ingo separately as part of the x86 series, just > airing it here for thoroughness). > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > Signed-off-by: Mike Travis <travis@sgi.com> > Cc: Ingo Molnar <mingo@redhat.com> I've pulled this patch into the queue for my cpus4096-for-ingo tree. [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 I can also line up a queue for sched related changes: [PATCH 4/4] cpumask: Replace cpu_coregroup_map with cpu_coregroup_map() Is there any status on the corresponding changes for sparc, s390? (I assume that they'll need to be merged into linux-next?) [PATCH 2/4] cpumask: cpu_coregroup_mask(): sparc [PATCH 3/4] cpumask: cpu_coregroup_mask(): s390 Thanks, Mike > --- > arch/x86/include/asm/topology.h | 1 + > arch/x86/kernel/smpboot.c | 11 ++++++++--- > 2 files changed, 9 insertions(+), 3 deletions(-) > > diff -r 11a884ebd99b arch/x86/include/asm/topology.h > --- a/arch/x86/include/asm/topology.h Thu Nov 20 13:54:24 2008 +1030 > +++ b/arch/x86/include/asm/topology.h Thu Nov 20 13:55:44 2008 +1030 > @@ -231,6 +231,7 @@ > #endif > > extern cpumask_t cpu_coregroup_map(int cpu); > +extern const struct cpumask *cpu_coregroup_mask(int cpu); > > #ifdef ENABLE_TOPO_DEFINES > #define topology_physical_package_id(cpu) (cpu_data(cpu).phys_proc_id) > diff -r 11a884ebd99b arch/x86/kernel/smpboot.c > --- a/arch/x86/kernel/smpboot.c Thu Nov 20 13:54:24 2008 +1030 > +++ b/arch/x86/kernel/smpboot.c Thu Nov 20 13:55:44 2008 +1030 > @@ -497,7 +497,7 @@ > } > > /* maps the cpu to the sched domain representing multi-core */ > -cpumask_t cpu_coregroup_map(int cpu) > +const struct cpumask *cpu_coregroup_mask(int cpu) > { > struct cpuinfo_x86 *c = &cpu_data(cpu); > /* > @@ -505,9 +505,14 @@ > * And for power savings, we return cpu_core_map > */ > if (sched_mc_power_savings || sched_smt_power_savings) > - return per_cpu(cpu_core_map, cpu); > + return &per_cpu(cpu_core_map, cpu); > else > - return c->llc_shared_map; > + return &c->llc_shared_map; > +} > + > +cpumask_t cpu_coregroup_map(int cpu) > +{ > + return *cpu_coregroup_mask(cpu); > } > > static void impress_friends(void) > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 2008-12-17 22:54 ` [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 Mike Travis @ 2008-12-17 23:02 ` Mike Travis 2008-12-18 6:14 ` Rusty Russell 1 sibling, 0 replies; 3+ messages in thread From: Mike Travis @ 2008-12-17 23:02 UTC (permalink / raw) To: Rusty Russell Cc: Ingo Molnar, Stephen Rothwell, LKML, linux-next, Jack Steiner Mike Travis wrote: > Rusty Russell wrote: >> Like cpu_coregroup_map, but returns a (const) pointer. >> >> (This will go to Ingo separately as part of the x86 series, just >> airing it here for thoroughness). >> >> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >> Signed-off-by: Mike Travis <travis@sgi.com> >> Cc: Ingo Molnar <mingo@redhat.com> > > I've pulled this patch into the queue for my cpus4096-for-ingo tree. > > [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 > > I can also line up a queue for sched related changes: > > [PATCH 4/4] cpumask: Replace cpu_coregroup_map with cpu_coregroup_map() > > Is there any status on the corresponding changes for sparc, s390? (I assume > that they'll need to be merged into linux-next?) > > [PATCH 2/4] cpumask: cpu_coregroup_mask(): sparc > [PATCH 3/4] cpumask: cpu_coregroup_mask(): s390 Oops, never mind. I just noticed that all 4 have already been pushed via linux-next. Ingo - how do we get these back into -tip for testing with other cpus4096 changes? Do I need to do anything? Thanks, Mike ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 2008-12-17 22:54 ` [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 Mike Travis 2008-12-17 23:02 ` Mike Travis @ 2008-12-18 6:14 ` Rusty Russell 1 sibling, 0 replies; 3+ messages in thread From: Rusty Russell @ 2008-12-18 6:14 UTC (permalink / raw) To: Mike Travis; +Cc: Ingo Molnar, Stephen Rothwell, LKML, linux-next, Jack Steiner On Thursday 18 December 2008 09:24:19 Mike Travis wrote: > Rusty Russell wrote: > > Like cpu_coregroup_map, but returns a (const) pointer. > > > > (This will go to Ingo separately as part of the x86 series, just > > airing it here for thoroughness). > > > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > > Signed-off-by: Mike Travis <travis@sgi.com> > > Cc: Ingo Molnar <mingo@redhat.com> > > I've pulled this patch into the queue for my cpus4096-for-ingo tree. > > [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 > > I can also line up a queue for sched related changes: > > [PATCH 4/4] cpumask: Replace cpu_coregroup_map with cpu_coregroup_map() > > Is there any status on the corresponding changes for sparc, s390? (I assume > that they'll need to be merged into linux-next?) > > [PATCH 2/4] cpumask: cpu_coregroup_mask(): sparc > [PATCH 3/4] cpumask: cpu_coregroup_mask(): s390 You can't take 4/4 until 2/4 and 3/4 are merged, and since it's not x86-specific as well, we'll leave it in my tree. Thanks, Rusty. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-12-18 6:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200812011646.35018.rusty@rustcorp.com.au>
2008-12-17 22:54 ` [PATCH 1/4] cpumask: cpu_coregroup_mask(): x86 Mike Travis
2008-12-17 23:02 ` Mike Travis
2008-12-18 6:14 ` Rusty Russell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).