[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090313045516.GA27326@elte.hu>
Date: Fri, 13 Mar 2009 05:55:16 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Mike Travis <travis@....com>
Subject: Re: [PULL] x86 cpumask work
* Rusty Russell <rusty@...tcorp.com.au> wrote:
> On Friday 13 March 2009 13:50:15 Ingo Molnar wrote:
> >
> > * Rusty Russell <rusty@...tcorp.com.au> wrote:
> >
> > > On Friday 13 March 2009 11:27:43 Ingo Molnar wrote:
> > > >
> > > > * Rusty Russell <rusty@...tcorp.com.au> wrote:
> > > > > Missing a core patch (it even got a compile warning with that
> > > > > config).
> > > > So it's manual work and sometimes i notice them amongst a
> > > > boatload of other warnings, sometimes i dont.
> > >
> > > Me too :( I thought you were starting a de-warning tree? I'd
> > > be happy to send you patches (particularly, exporting
> > > deprecated symbols should not give a warning!).
> >
> > Yeah - i have a de-warning tree, but it's not yet fully up and
> > running for -tip qa automation.
> >
> > > > > But there's something else wrong. Firing up my 64-bit
> > > > > test box now.
> > > >
> > > > Great - so you can reproduce. Thanks,
> > >
> > > Yep, and I'm running some stress tests as well now.
> > >
> > > Perhaps throw away that tree, and I'll feed you a new one (the
> > > core patch needs to go at the front), but I can work either
> > > way.
> >
> > Ok, i dropped it back to d95c357.
> >
> > Suggestion for future workflow: we wouldnt have these somewhat
> > stressful (and stressful to you mostly!), large hickups and
> > history-less trees if you sent stuff more gradually and not so
> > close to the merge window. You exposed some of your changes to
> > linux-next but that's not nearly enough testing in practice for
> > x86-affecting patches.
>
> Yes, I wanted to complete the patchset to make sure I wasn't going to hit
> some subtle problem.
>
> OK, please check the first patch (it's a new addition, I *think* using
> the topology_* macros is right here), and the other change is:
>
> Here's the other change: it's a little ugly (AFAICT boot_cpu_data isn't
> even *used* on 64 bit, so a cleanup may be in order):
>
> +++ b/arch/x86/kernel/smpboot.c
> @@ -329,6 +329,23 @@ notrace static void __cpuinit start_seco
> cpu_idle();
> }
>
> +#ifdef CONFIG_CPUMASK_OFFSTACK
> +/* In this case, llc_shared_map is a pointer to a cpumask. */
> +static inline void copy_cpuinfo_x86(struct cpuinfo_x86 *dst,
> + const struct cpuinfo_x86 *src)
> +{
> + struct cpumask *llc = dst->llc_shared_map;
> + *dst = *src;
> + dst->llc_shared_map = llc;
> +}
> +#else
> +static inline void copy_cpuinfo_x86(struct cpuinfo_x86 *dst,
> + const struct cpuinfo_x86 *src)
> +{
> + *dst = *src;
> +}
> +#endif /* CONFIG_CPUMASK_OFFSTACK */
> +
> /*
> * The bootstrap kernel entry code has set these up. Save them for
> * a given CPU
> @@ -338,7 +355,7 @@ void __cpuinit smp_store_cpu_info(int id
> {
> struct cpuinfo_x86 *c = &cpu_data(id);
>
> - *c = boot_cpu_data;
> + copy_cpuinfo_x86(c, &boot_cpu_data);
> c->cpu_index = id;
> if (id != 0)
> identify_secondary_cpu(c);
>
> BTW, these didn't go thru linux-next: your testing is better and your
> tree is too different or me to ask Stephen to merge.
>
> Thanks!
> Rusty.
>
> The following changes since commit d95c3578120e5bc4784069439f00ccb1b5f87717:
> Ingo Molnar (1):
> Merge branch 'x86/core' into cpus4096
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-x86.git cpus4096
Pulled, thanks Rusty!
Will let you know if something breaks.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists