[PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask - Kernel

This is a discussion on [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask - Kernel ; On Friday 24 October 2008 01:20:25 Ingo Molnar wrote: > Thomas has started a -tip cross-build test, and there's massive > cross-build failures as well due to the cpumask changes: Yes. linux-next reported the same thing. I've backed out various ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 77 of 77

Thread: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

  1. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    > Thomas has started a -tip cross-build test, and there's massive
    > cross-build failures as well due to the cpumask changes:


    Yes. linux-next reported the same thing. I've backed out various arch
    changes for this reason.

    > it seems to me that this commit is massively borked:
    >
    > 4a792c2: cpumask: make CONFIG_NR_CPUS always valid


    Yep. This is the big one I dropped. There are a few others; Mike is just
    porting the changes across to your tree now.

    Cheers,
    Rusty.
    --
    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/

  2. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    Rusty Russell wrote:
    > On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    >> Thomas has started a -tip cross-build test, and there's massive
    >> cross-build failures as well due to the cpumask changes:

    >
    > Yes. linux-next reported the same thing. I've backed out various arch
    > changes for this reason.
    >
    >> it seems to me that this commit is massively borked:
    >>
    >> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid

    >
    > Yep. This is the big one I dropped. There are a few others; Mike is just
    > porting the changes across to your tree now.
    >
    > Cheers,
    > Rusty.


    Hi Ingo,

    It would seem easier to back out previous patches and apply the replacements.
    Does this work for you?

    Thanks,
    Mike
    --
    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/

  3. Re: [PATCH 35/35] x86: clean up speedctep-centrino and reduce cpumask_t usage From: Rusty Russell <rusty@rustcorp.com.au>

    On Thu, Oct 23, 2008 at 02:04:44PM +0200, Ingo Molnar wrote:
    >
    > * Rusty Russell wrote:
    >
    > > On Thursday 23 October 2008 13:09:01 Mike Travis wrote:
    > > > 1) The #ifdef CONFIG_HOTPLUG_CPU seems unnecessary these days.
    > > > 2) The loop can simply skip over offline cpus, rather than creating a tmp
    > > > mask.
    > > > 3) set_mask is set to either a single cpu or all online cpus in a
    > > > policy. Since it's just used for set_cpus_allowed(), any offline cpus in a
    > > > policy don't matter, so we can just use cpumask_of_cpu() or the
    > > > policy->cpus.

    > >
    > > Note that this cleanup stands alone; it's just that I read this code I
    > > couldn't help but tidy it up.
    > >
    > > Ingo: do you just want to put this in your normal tree for sending to
    > > Linus?

    >
    > hm, cpufreq stuff belongs into davej's tree.
    >
    > i skipped #34 and #35 for now, we can live without them, correct?


    If those patches are dependant upon the others, I can live with them
    going through another tree. There's nothing pending for speedstep-centrino
    in cpufreq anyway.

    Dave

    --
    http://www.codemonkey.org.uk
    --
    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/

  4. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask


    * Rusty Russell wrote:

    > On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    > > Thomas has started a -tip cross-build test, and there's massive
    > > cross-build failures as well due to the cpumask changes:

    >
    > Yes. linux-next reported the same thing. I've backed out various
    > arch changes for this reason.
    >
    > > it seems to me that this commit is massively borked:
    > >
    > > 4a792c2: cpumask: make CONFIG_NR_CPUS always valid

    >
    > Yep. This is the big one I dropped. There are a few others; Mike is
    > just porting the changes across to your tree now.


    guys. I already spent hours integrating the "latest" of this stuff today
    and established baseline quality for it on x86. I've dropped 4a792c2 and
    pushed out a new tip/cpus4096-v2, please send append-only patches for
    the rest of the changes.

    Ingo
    --
    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/

  5. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    Ingo Molnar wrote:
    > * Rusty Russell wrote:
    >
    >> On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    >>> Thomas has started a -tip cross-build test, and there's massive
    >>> cross-build failures as well due to the cpumask changes:

    >> Yes. linux-next reported the same thing. I've backed out various
    >> arch changes for this reason.
    >>
    >>> it seems to me that this commit is massively borked:
    >>>
    >>> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid

    >> Yep. This is the big one I dropped. There are a few others; Mike is
    >> just porting the changes across to your tree now.

    >
    > guys. I already spent hours integrating the "latest" of this stuff today
    > and established baseline quality for it on x86. I've dropped 4a792c2 and
    > pushed out a new tip/cpus4096-v2, please send append-only patches for
    > the rest of the changes.
    >
    > Ingo


    Ok, no problem. I was integrating in the changes you already made so they
    would not be dropped. But I'll send "update" patches instead of "replacement"
    patches if you prefer.

    Thanks,
    Mike
    --
    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/

  6. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask


    * Mike Travis wrote:

    > Rusty Russell wrote:
    > > On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    > >> Thomas has started a -tip cross-build test, and there's massive
    > >> cross-build failures as well due to the cpumask changes:

    > >
    > > Yes. linux-next reported the same thing. I've backed out various arch
    > > changes for this reason.
    > >
    > >> it seems to me that this commit is massively borked:
    > >>
    > >> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid

    > >
    > > Yep. This is the big one I dropped. There are a few others; Mike is just
    > > porting the changes across to your tree now.
    > >
    > > Cheers,
    > > Rusty.

    >
    > Hi Ingo,
    >
    > It would seem easier to back out previous patches and apply the
    > replacements. Does this work for you?


    no, it does not work fine. As i said, i reworked various small bits
    along the way of reviewing and integrating them, under the obvious
    assumption that you submitted the latest and greatest. I spent hours
    testing every single step as well. If you cannot get your workflow right
    then we cannot have this stuff in v2.6.28.

    So ... please send append-only changes against tip/cpus4096-v2. We can
    squash/backmerge any bits to keep it all clean, but all changes have to
    be fully visible and fully reviewed from now on, because time is running
    short.

    Ingo
    --
    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/

  7. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask


    * Mike Travis wrote:

    > Ingo Molnar wrote:
    > > * Rusty Russell wrote:
    > >
    > >> On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    > >>> Thomas has started a -tip cross-build test, and there's massive
    > >>> cross-build failures as well due to the cpumask changes:
    > >> Yes. linux-next reported the same thing. I've backed out various
    > >> arch changes for this reason.
    > >>
    > >>> it seems to me that this commit is massively borked:
    > >>>
    > >>> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid
    > >> Yep. This is the big one I dropped. There are a few others; Mike is
    > >> just porting the changes across to your tree now.

    > >
    > > guys. I already spent hours integrating the "latest" of this stuff today
    > > and established baseline quality for it on x86. I've dropped 4a792c2 and
    > > pushed out a new tip/cpus4096-v2, please send append-only patches for
    > > the rest of the changes.
    > >
    > > Ingo

    >
    > Ok, no problem. I was integrating in the changes you already made so
    > they would not be dropped. But I'll send "update" patches instead of
    > "replacement" patches if you prefer.


    how big are the deltas? You might send a single interdiff - it's
    supposed to be all small, right?

    Ingo
    --
    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/

  8. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    Ingo Molnar wrote:
    > * Mike Travis wrote:
    >
    >> Ingo Molnar wrote:
    >>> * Rusty Russell wrote:
    >>>
    >>>> On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    >>>>> Thomas has started a -tip cross-build test, and there's massive
    >>>>> cross-build failures as well due to the cpumask changes:
    >>>> Yes. linux-next reported the same thing. I've backed out various
    >>>> arch changes for this reason.
    >>>>
    >>>>> it seems to me that this commit is massively borked:
    >>>>>
    >>>>> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid
    >>>> Yep. This is the big one I dropped. There are a few others; Mike is
    >>>> just porting the changes across to your tree now.
    >>> guys. I already spent hours integrating the "latest" of this stuff today
    >>> and established baseline quality for it on x86. I've dropped 4a792c2 and
    >>> pushed out a new tip/cpus4096-v2, please send append-only patches for
    >>> the rest of the changes.
    >>>
    >>> Ingo

    >> Ok, no problem. I was integrating in the changes you already made so
    >> they would not be dropped. But I'll send "update" patches instead of
    >> "replacement" patches if you prefer.

    >
    > how big are the deltas? You might send a single interdiff - it's
    > supposed to be all small, right?
    >
    > Ingo


    It's pretty trivial, mostly removing things. The big problem is Rusty
    based his on Linus' tree (and he's offline now), so I need to apply his
    patches to that tree and then generate "diff" patches for your tree.

    Btw, I'm still having trouble building a "baseline" config using the
    cpus4096-v2 branch that actually boots. (UP boots ok.) Is this the
    correct .git/config:

    [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    [remote "linus"]
    url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    fetch = +refs/heads/*:refs/remotes/linus/*
    [remote "tip"]
    url = git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
    fetch = +refs/heads/*:refs/remotes/tip/*
    [branch "tip-latest"]
    remote = tip
    merge = refs/heads/master
    [branch "cpus4096-v2"]
    remote = tip
    merge = refs/heads/cpus4096-v2


    It won't let me do a:

    mkdir linux-2.6.tip
    cd linux-2.6.tip
    git-init-db
    git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
    git-remote update

    git-checkout -b cpus4096-v2 tip/cpus4096-v2
    git checkout: updating paths is incompatible with switching branches/forcing
    Did you intend to checkout 'tip/cpus4906-v2' which can not be resolved as commit?

    or:

    git-checkout tip/cpus4906-v2
    error: pathspec 'tip/cpus4906-v2' did not match any file(s) known to git.
    Did you forget to 'git add'?

    Thanks,
    Mike


    --
    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/

  9. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask


    * Mike Travis wrote:

    > git-checkout -b cpus4096-v2 tip/cpus4096-v2
    > git checkout: updating paths is incompatible with switching branches/forcing
    > Did you intend to checkout 'tip/cpus4906-v2' which can not be resolved as commit?


    see the typo in the error message?

    >
    > or:
    >
    > git-checkout tip/cpus4906-v2
    > error: pathspec 'tip/cpus4906-v2' did not match any file(s) known to git.
    > Did you forget to 'git add'?


    the 4906/4096 typo in shown in this error message as well.

    Ingo
    --
    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/

  10. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    Ingo Molnar wrote:
    > * Mike Travis wrote:
    >
    >> git-checkout -b cpus4096-v2 tip/cpus4096-v2
    >> git checkout: updating paths is incompatible with switching branches/forcing
    >> Did you intend to checkout 'tip/cpus4906-v2' which can not be resolved as commit?

    >
    > see the typo in the error message?
    >
    >> or:
    >>
    >> git-checkout tip/cpus4906-v2
    >> error: pathspec 'tip/cpus4906-v2' did not match any file(s) known to git.
    >> Did you forget to 'git add'?

    >
    > the 4906/4096 typo in shown in this error message as well.
    >
    > Ingo


    Sorry, that was a cut and paste error in this example. I've tried both these
    ..git/config's and both hang during bootup:


    [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    [remote "linus"]
    url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    fetch = +refs/heads/*:refs/remotes/linus/*
    [remote "tip"]
    url = git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
    fetch = +refs/heads/*:refs/remotes/tip/*
    [branch "cpus4096-v2"]
    remote = tip
    merge = refs/heads/cpus4096-v2


    [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    [remote "linus"]
    url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    fetch = +refs/heads/*:refs/remotes/linus/*
    [remote "tip"]
    url = git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
    fetch = +refs/heads/*:refs/remotes/tip/*
    [branch "tip-latest"]
    remote = tip
    merge = refs/heads/master
    [branch "cpus4096-v2"]
    remote = tip
    merge = refs/heads/cpus4096-v2
    --
    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/

  11. [PATCH 1/1]: cpumask: fix compiler errors/warnings

    From: Rusty Russel

    Ingo Molnar wrote:
    > * Rusty Russell wrote:
    >
    >> On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    >>> Thomas has started a -tip cross-build test, and there's massive
    >>> cross-build failures as well due to the cpumask changes:

    >> Yes. linux-next reported the same thing. I've backed out various
    >> arch changes for this reason.
    >>
    >>> it seems to me that this commit is massively borked:
    >>>
    >>> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid

    >> Yep. This is the big one I dropped. There are a few others; Mike is
    >> just porting the changes across to your tree now.

    >
    > guys. I already spent hours integrating the "latest" of this stuff today
    > and established baseline quality for it on x86. I've dropped 4a792c2 and
    > pushed out a new tip/cpus4096-v2, please send append-only patches for
    > the rest of the changes.
    >
    > Ingo


    Here are the only changes I could find from Rusty's last patches that
    apply to tip/cpus4096-v2.

    * Fix NR_CPUS reference in arch/powerpc/platforms/cell/spu_base.c

    * modify arch/x86/Kconfig so CONFIG_NR_CPUS is always defined. Also it
    does not prompt if MAXSMP is set.

    * change include/linux/threads.h so CONFIG_NR_CPUS is defined for those
    arch's that do not define it.

    Signed-of-by: Rusty Russel
    Signed-of-by: Mike Travis
    ---
    Note I haven't been able test anything on this branch, patches or not.
    (Everything that has SMP set hangs during startup. I've tried a number
    of approaches to creating a source tree but all fail.)
    ---
    arch/powerpc/platforms/cell/spu_base.c | 9 ++++++---
    arch/x86/Kconfig | 2 +-
    include/linux/threads.h | 16 ++++++++--------
    3 files changed, 15 insertions(+), 12 deletions(-)

    --- linux-2.6-cpus4096-v2.orig/arch/powerpc/platforms/cell/spu_base.c
    +++ linux-2.6-cpus4096-v2/arch/powerpc/platforms/cell/spu_base.c
    @@ -111,10 +111,13 @@ void spu_flush_all_slbs(struct mm_struct
    */
    static inline void mm_needs_global_tlbie(struct mm_struct *mm)
    {
    - int nr = (NR_CPUS > 1) ? NR_CPUS : NR_CPUS + 1;
    -
    /* Global TLBIE broadcast required with SPEs. */
    - __cpus_setall(&mm->cpu_vm_mask, nr);
    + if (NR_CPUS > 1)
    + cpumask_setall(&mm->cpu_vm_mask);
    + else {
    + cpumask_set_cpu(0, &mm->cpu_vm_mask);
    + cpumask_set_cpu(1, &mm->cpu_vm_mask);
    + }
    }

    void spu_associate_mm(struct spu *spu, struct mm_struct *mm)
    --- linux-2.6-cpus4096-v2.orig/arch/x86/Kconfig
    +++ linux-2.6-cpus4096-v2/arch/x86/Kconfig
    @@ -585,9 +585,9 @@ config MAXSMP
    If unsure, say N.

    config NR_CPUS
    - depends on SMP
    int "Maximum number of CPUs" if SMP && !MAXSMP
    range 2 512 if SMP && !MAXSMP
    + default "1" if !SMP
    default "4096" if MAXSMP
    default "32" if X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000
    default "8"
    --- linux-2.6-cpus4096-v2.orig/include/linux/threads.h
    +++ linux-2.6-cpus4096-v2/include/linux/threads.h
    @@ -8,17 +8,17 @@
    */

    /*
    - * Maximum supported processors that can run under SMP. This value is
    - * set via configure setting. The maximum is equal to the size of the
    - * bitmasks used on that platform, i.e. 32 or 64. Setting this smaller
    - * saves quite a bit of memory.
    + * Maximum supported processors. Setting this smaller saves quite a
    + * bit of memory. Use nr_cpu_ids instead of this except for static bitmaps.
    */
    -#ifdef CONFIG_SMP
    -#define NR_CPUS CONFIG_NR_CPUS
    -#else
    -#define NR_CPUS 1
    +#ifndef CONFIG_NR_CPUS
    +/* FIXME: This should be fixed in the arch's Kconfig */
    +#define CONFIG_NR_CPUS 1
    #endif

    +/* Places which use this should consider cpumask_var_t. */
    +#define NR_CPUS CONFIG_NR_CPUS
    +
    #define MIN_THREADS_LEFT_FOR_ROOT 4

    /*

    --
    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/

  12. Re: [bug #2] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    On Friday 24 October 2008 03:09:59 Ingo Molnar wrote:
    > * Mike Travis wrote:
    > > Rusty Russell wrote:
    > > > On Friday 24 October 2008 01:20:25 Ingo Molnar wrote:
    > > >> Thomas has started a -tip cross-build test, and there's massive
    > > >> cross-build failures as well due to the cpumask changes:
    > > >
    > > > Yes. linux-next reported the same thing. I've backed out various arch
    > > > changes for this reason.
    > > >
    > > >> it seems to me that this commit is massively borked:
    > > >>
    > > >> 4a792c2: cpumask: make CONFIG_NR_CPUS always valid
    > > >
    > > > Yep. This is the big one I dropped. There are a few others; Mike is
    > > > just porting the changes across to your tree now.
    > > >
    > > > Cheers,
    > > > Rusty.

    > >
    > > Hi Ingo,
    > >
    > > It would seem easier to back out previous patches and apply the
    > > replacements. Does this work for you?

    >
    > no, it does not work fine. As i said, i reworked various small bits
    > along the way of reviewing and integrating them, under the obvious
    > assumption that you submitted the latest and greatest. I spent hours
    > testing every single step as well. If you cannot get your workflow right
    > then we cannot have this stuff in v2.6.28.


    Indeed, though to be honest it's been easier to do the fixes in linux-next.

    Here's the interdiff; it's not too bad (you already reverted the
    arch-destroying config changes).

    Summary:
    1) Alpha defines cpu_possible_map to cpu_present_map: this isn't possible
    under centralization, so just manipulate both together.
    2) IA64, cris and m32r gratuitously re-declared cpu_possible_map; remove.
    3) PowerPC Cell used __cpu_setall in a questionable way.
    Arnd approved this version.
    4) That also leads to weakening the BUG_ON() to WARN_ON_ONCE() for
    CONFIG_DEBUG_PER_CPU_MAPS; Arnd wants to be reminded, but only once
    5) Revert most of S390 smp_call_function_mask->smp_call_function_many: it's
    safer to just do the minimal conversion.
    6) Remove __deprecated from smp_call_function_mask: we're not pushing
    replacement patches yet so it's not appropriate, and it breaks sparc64
    which compiles arch/sparc with -Werror.
    7) Hack header to set CONFIG_NR_CPUS for UP on archs; safer than touching
    Kconfigs for them. Also update comment.

    Thanks,
    Rusty.

    diff --git a/arch/alpha/include/asm/smp.h b/arch/alpha/include/asm/smp.h
    index 544c69a..547e909 100644
    --- a/arch/alpha/include/asm/smp.h
    +++ b/arch/alpha/include/asm/smp.h
    @@ -45,7 +45,6 @@ extern struct cpuinfo_alpha cpu_data[NR_CPUS];
    #define raw_smp_processor_id() (current_thread_info()->cpu)

    extern int smp_num_cpus;
    -#define cpu_possible_map cpu_present_map

    extern void arch_send_call_function_single_ipi(int cpu);
    extern void arch_send_call_function_ipi(cpumask_t mask);
    diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
    index 351407e..f238370 100644
    --- a/arch/alpha/kernel/process.c
    +++ b/arch/alpha/kernel/process.c
    @@ -94,6 +94,7 @@ common_shutdown_1(void *generic_ptr)
    flags |= 0x00040000UL; /* "remain halted" */
    *pflags = flags;
    cpu_clear(cpuid, cpu_present_map);
    + cpu_clear(cpuid, cpu_possible_map);
    halt();
    }
    #endif
    @@ -120,6 +121,7 @@ common_shutdown_1(void *generic_ptr)
    #ifdef CONFIG_SMP
    /* Wait for the secondaries to halt. */
    cpu_clear(boot_cpuid, cpu_present_map);
    + cpu_clear(boot_cpuid, cpu_possible_map);
    while (cpus_weight(cpu_present_map))
    barrier();
    #endif
    diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
    index ac26335..ce6791a 100644
    --- a/arch/alpha/kernel/smp.c
    +++ b/arch/alpha/kernel/smp.c
    @@ -435,6 +435,7 @@ setup_smp(void)
    ((char *)cpubase + i*hwrpb->processor_size);
    if ((cpu->flags & 0x1cc) == 0x1cc) {
    smp_num_probed++;
    + cpu_set(i, cpu_possible_map);
    cpu_set(i, cpu_present_map);
    cpu->pal_revision = boot_cpu_palrev;
    }
    @@ -468,6 +469,7 @@ smp_prepare_cpus(unsigned int max_cpus)

    /* Nothing to do on a UP box, or when told not to. */
    if (smp_num_probed == 1 || max_cpus == 0) {
    + cpu_possible_map = cpumask_of_cpu(boot_cpuid);
    cpu_present_map = cpumask_of_cpu(boot_cpuid);
    printk(KERN_INFO "SMP mode deactivated.\n");
    return;
    diff --git a/arch/ia64/include/asm/smp.h b/arch/ia64/include/asm/smp.h
    index 12d96e0..21c4023 100644
    --- a/arch/ia64/include/asm/smp.h
    +++ b/arch/ia64/include/asm/smp.h
    @@ -57,7 +57,6 @@ extern struct smp_boot_data {

    extern char no_int_routing __devinitdata;

    -extern cpumask_t cpu_online_map;
    extern cpumask_t cpu_core_map[NR_CPUS];
    DECLARE_PER_CPU(cpumask_t, cpu_sibling_map);
    extern int smp_num_siblings;
    diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
    index a5bdb89..402c183 100644
    --- a/arch/powerpc/platforms/cell/spu_base.c
    +++ b/arch/powerpc/platforms/cell/spu_base.c
    @@ -111,10 +111,11 @@ void spu_flush_all_slbs(struct mm_struct *mm)
    */
    static inline void mm_needs_global_tlbie(struct mm_struct *mm)
    {
    - int nr = (NR_CPUS > 1) ? NR_CPUS : NR_CPUS + 1;
    + cpumask_setall(&mm->cpu_vm_mask);

    /* Global TLBIE broadcast required with SPEs. */
    - __cpus_setall(&mm->cpu_vm_mask, nr);
    + if (nr_cpu_ids == 1)
    + cpumask_set_cpu(1, &mm->cpu_vm_mask);
    }

    void spu_associate_mm(struct spu *spu, struct mm_struct *mm)
    diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
    index 10e7f97..29a3eb1 100644
    --- a/arch/s390/kernel/smp.c
    +++ b/arch/s390/kernel/smp.c
    @@ -103,7 +103,7 @@ static void do_call_function(void)
    }

    static void __smp_call_function_map(void (*func) (void *info), void *info,
    - int wait, struct cpumask *map)
    + int wait, cpumask_t map)
    {
    struct call_data_struct data;
    int cpu, local = 0;
    @@ -163,16 +163,14 @@ out:
    * You must not call this function with disabled interrupts, from a
    * hardware interrupt handler or from a bottom half.
    */
    -
    -/* protected by call_lock */
    -static DEFINE_BITMAP(smp_call_map, CONFIG_NR_CPUS);
    -
    int smp_call_function(void (*func) (void *info), void *info, int wait)
    {
    + cpumask_t map;
    +
    spin_lock(&call_lock);
    - cpumask_copy(to_cpumask(smp_call_map), cpu_online_mask);
    - cpumask_clear_cpu(smp_processor_id(), to_cpumask(smp_call_map));
    - __smp_call_function_map(func, info, wait, to_cpumask(smp_call_map));
    + map = cpu_online_map;
    + cpu_clear(smp_processor_id(), map);
    + __smp_call_function_map(func, info, wait, map);
    spin_unlock(&call_lock);
    return 0;
    }
    @@ -194,8 +192,7 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
    int wait)
    {
    spin_lock(&call_lock);
    - cpumask_copy(to_cpumask(smp_call_map), cpumask_of(cpu));
    - __smp_call_function_map(func, info, wait, cpumask_of(cpu));
    + __smp_call_function_map(func, info, wait, cpumask_of_cpu(cpu));
    spin_unlock(&call_lock);
    return 0;
    }
    @@ -216,13 +213,13 @@ EXPORT_SYMBOL(smp_call_function_single);
    * You must not call this function with disabled interrupts or from a
    * hardware interrupt handler or from a bottom half handler.
    */
    -int smp_call_function_many(const struct cpumask *mask,
    +int smp_call_function_many(const struct cpumask *maskp,
    void (*func)(void *), void *info, bool wait)
    {
    + cpumask_t mask = *maskp;
    spin_lock(&call_lock);
    - cpumask_copy(to_cpumask(smp_call_map), cpu_online_mask);
    - cpumask_clear_cpu(smp_processor_id(), to_cpumask(smp_call_map));
    - __smp_call_function_map(func, info, wait, to_cpumask(smp_call_map));
    + cpu_clear(smp_processor_id(), mask);
    + __smp_call_function_map(func, info, wait, mask);
    spin_unlock(&call_lock);
    return 0;
    }
    diff --git a/include/asm-cris/smp.h b/include/asm-cris/smp.h
    index dba33ab..c615a06 100644
    --- a/include/asm-cris/smp.h
    +++ b/include/asm-cris/smp.h
    @@ -4,7 +4,6 @@
    #include

    extern cpumask_t phys_cpu_present_map;
    -extern cpumask_t cpu_possible_map;

    #define raw_smp_processor_id() (current_thread_info()->cpu)

    diff --git a/include/asm-m32r/smp.h b/include/asm-m32r/smp.h
    index c5dd669..b96a6d2 100644
    --- a/include/asm-m32r/smp.h
    +++ b/include/asm-m32r/smp.h
    @@ -63,8 +63,6 @@ extern volatile int cpu_2_physid[NR_CPUS];
    #define raw_smp_processor_id() (current_thread_info()->cpu)

    extern cpumask_t cpu_callout_map;
    -extern cpumask_t cpu_possible_map;
    -extern cpumask_t cpu_present_map;

    static __inline__ int hard_smp_processor_id(void)
    {
    diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
    index d1f22ee..295d9e8 100644
    --- a/include/linux/cpumask.h
    +++ b/include/linux/cpumask.h
    @@ -254,8 +254,7 @@ extern cpumask_t _unused_cpumask_arg_;
    static inline unsigned int cpumask_check(unsigned int cpu)
    {
    #ifdef CONFIG_DEBUG_PER_CPU_MAPS
    - /* This breaks at runtime. */
    - BUG_ON(cpu >= nr_cpumask_bits);
    + WARN_ON_ONCE(cpu >= nr_cpumask_bits);
    #endif /* CONFIG_DEBUG_PER_CPU_MAPS */
    return cpu;
    }
    diff --git a/include/linux/smp.h b/include/linux/smp.h
    index c7bc2fa..748ebc9 100644
    --- a/include/linux/smp.h
    +++ b/include/linux/smp.h
    @@ -71,7 +71,7 @@ int smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
    void __smp_call_function_single(int cpuid, struct call_single_data *data);

    /* Use smp_call_function_many, which takes a pointer to the mask. */
    -static inline int __deprecated
    +static inline int
    smp_call_function_mask(cpumask_t mask, void(*func)(void *info), void *info,
    int wait)
    {
    diff --git a/include/linux/threads.h b/include/linux/threads.h
    index 38d1a5d..08a0286 100644
    --- a/include/linux/threads.h
    +++ b/include/linux/threads.h
    @@ -8,17 +8,18 @@
    */

    /*
    - * Maximum supported processors that can run under SMP. This value is
    - * set via configure setting. The maximum is equal to the size of the
    - * bitmasks used on that platform, i.e. 32 or 64. Setting this smaller
    - * saves quite a bit of memory.
    + * Maximum supported processors that can run under SMP. Setting this smaller
    + * saves quite a bit of memory. Use nr_cpu_ids instead of this except for
    + * static bitmaps.
    */
    -#ifdef CONFIG_SMP
    -#define NR_CPUS CONFIG_NR_CPUS
    -#else
    -#define NR_CPUS 1
    +#ifndef CONFIG_NR_CPUS
    +/* FIXME: This should be fixed in the arch's Kconfig */
    +#define CONFIG_NR_CPUS 1
    #endif

    +/* Places which use this should consider cpumask_var_t. */
    +#define NR_CPUS CONFIG_NR_CPUS
    +
    #define MIN_THREADS_LEFT_FOR_ROOT 4

    /*
    --
    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/

  13. Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    On Thursday 23 October 2008 23:03:22 Ingo Molnar wrote:
    > I also added "Impact:" lines to every commit - a one-line summary of the
    > expected outcome of the change. (Please double-check those impact lines
    > - if you see anything odd it means that i missed some detail in the
    > commit - that will need to be fixed if it happens.)


    Note that "removed" and "deprecated" are using the terms loosely. No old API
    was removed, and I didn't actually mark anything __deprecated (I just
    documented it in the header).

    Here are my revisions:

    f1ad2eefc7644467a5b8bec38b540f40260f0f03:
    cpumask: cpu_all_mask and cpu_none_mask

    -Impact: introduce new constants, convert old usage to them
    +Impact: introduce new constants, convert core files.


    88e316949934e187e4f131d99bf156413632e56b
    cpumask: deprecate any_online_cpu() in favour of cpumask_any/cpumask_any_and

    -Impact: cleanup
    +Impact: new API, deprecate old


    4d57c437e6d239f46a881fdb04a57fb2664bfc97
    cpumask: cpumask_first/cpumask_next

    -Impact: remove old API, convert all users to new API
    +Impact: new API, deprecate old
    (We convert one place only)


    dfa1385db10e1b1d5a1687f0184d9c11735192aa
    cpumask: for_each_cpu(): for_each_cpu_mask which takes a pointer

    -Impact: remove old API, convert all users to new API
    +Impact: remove old API, convert core trivial users

    a55659d4f58eaacde2681298d003bbeeafb16436
    cpumask: cpumask_of(): cpumask_of_cpu() which returns a pointer

    -Impact: cleanup
    +Impact: new API, deprecate old API.

    Thanks,
    Rusty.
    --
    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/

  14. Re: [bug] Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask

    On Thursday 23 October 2008 23:55:29 Ingo Molnar wrote:
    > ok, the new cpumask code blew up in -tip testing, with various sorts of
    > slab corruptions during scheduler init:

    ....
    > i suspect it's due to:
    >
    > 01b8bd9: sched: cpumask: get rid of boutique sched.c allocations, use
    > cpumask_va


    Just drop it. It's a conversion, so it doesn't really belong in this "new
    API" stuff. Nothing depends on it, and we need to be sure it's that which is
    causing the blowup.

    Oh, and here's (one) problem:

    *nodemask = node_to_cpumask(cpu_to_node(i));

    This is an old-style cpumask_t assigment, but nodemask wasn't allocated
    NR_CPUS bits if CONFIG_CPUMASK_OFFSTACK. This is why assignment is banned
    (and will eventually fail compile), but that conversion hasn't been done on
    sched.c yet, so this patch is ahead of its time.

    Thanks,
    Rusty.
    --
    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/

  15. Re: [PATCH 00/35] cpumask: Replace cpumask_t with struct cpumask


    * Rusty Russell wrote:

    > On Thursday 23 October 2008 23:03:22 Ingo Molnar wrote:
    > > I also added "Impact:" lines to every commit - a one-line summary of the
    > > expected outcome of the change. (Please double-check those impact lines
    > > - if you see anything odd it means that i missed some detail in the
    > > commit - that will need to be fixed if it happens.)

    >
    > Note that "removed" and "deprecated" are using the terms loosely.
    > No old API was removed, and I didn't actually mark anything
    > __deprecated (I just documented it in the header).


    ok.

    > Here are my revisions:
    >
    > f1ad2eefc7644467a5b8bec38b540f40260f0f03:
    > cpumask: cpu_all_mask and cpu_none_mask
    >
    > -Impact: introduce new constants, convert old usage to them
    > +Impact: introduce new constants, convert core files.
    >
    >
    > 88e316949934e187e4f131d99bf156413632e56b
    > cpumask: deprecate any_online_cpu() in favour of cpumask_any/cpumask_any_and
    >
    > -Impact: cleanup
    > +Impact: new API, deprecate old
    >
    >
    > 4d57c437e6d239f46a881fdb04a57fb2664bfc97
    > cpumask: cpumask_first/cpumask_next
    >
    > -Impact: remove old API, convert all users to new API
    > +Impact: new API, deprecate old
    > (We convert one place only)
    >
    >
    > dfa1385db10e1b1d5a1687f0184d9c11735192aa
    > cpumask: for_each_cpu(): for_each_cpu_mask which takes a pointer
    >
    > -Impact: remove old API, convert all users to new API
    > +Impact: remove old API, convert core trivial users
    >
    > a55659d4f58eaacde2681298d003bbeeafb16436
    > cpumask: cpumask_of(): cpumask_of_cpu() which returns a pointer
    >
    > -Impact: cleanup
    > +Impact: new API, deprecate old API.


    i've propagated these impact-line fixes into tip/cpus4096-v2, thanks
    Rusty!

    And once we have something that works reasonably well we can do a
    final respin of this branch with all fixlets back-propagated, for good
    bisectability.

    the current variant, which force-disabled MAXSMP (i.e. only uses the
    non-dynamic cpumask_t branch), is looking good in my testing so far.
    (it has passed more than 100 boot tests today, on a handful of x86
    boxes)

    Ingo
    --
    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/

  16. Re: [PATCH 35/35] x86: clean up speedctep-centrino and reduce cpumask_t usage From: Rusty Russell <rusty@rustcorp.com.au>


    * Dave Jones wrote:

    > On Thu, Oct 23, 2008 at 02:04:44PM +0200, Ingo Molnar wrote:
    > >
    > > * Rusty Russell wrote:
    > >
    > > > On Thursday 23 October 2008 13:09:01 Mike Travis wrote:
    > > > > 1) The #ifdef CONFIG_HOTPLUG_CPU seems unnecessary these days.
    > > > > 2) The loop can simply skip over offline cpus, rather than creating a tmp
    > > > > mask.
    > > > > 3) set_mask is set to either a single cpu or all online cpus in a
    > > > > policy. Since it's just used for set_cpus_allowed(), any offline cpus in a
    > > > > policy don't matter, so we can just use cpumask_of_cpu() or the
    > > > > policy->cpus.
    > > >
    > > > Note that this cleanup stands alone; it's just that I read this code I
    > > > couldn't help but tidy it up.
    > > >
    > > > Ingo: do you just want to put this in your normal tree for sending to
    > > > Linus?

    > >
    > > hm, cpufreq stuff belongs into davej's tree.
    > >
    > > i skipped #34 and #35 for now, we can live without them, correct?

    >
    > If those patches are dependant upon the others, I can live with them
    > going through another tree. There's nothing pending for
    > speedstep-centrino in cpufreq anyway.


    ok - although the cleanups Rusty did look independent to me. We can
    just keep it in mind for the future, the whole topic is complex enough
    already as-is.

    Ingo
    --
    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/

  17. Re: [PATCH 29/35] cpumask: switch over to cpu_online/possible/active/present_mask From: Rusty Russell <rusty@rustcorp.com.au>

    --- linux-2.6.28.orig/include/linux/cpumask.h
    +++ linux-2.6.28/include/linux/cpumask.h
    ....
    +#define cpu_online_map (*(cpumask_t *)cpu_online_mask)

    This bit seems to be the reason why linux-next isn't building for ia64
    (tag next-20081029
    and next-20081030). With this error:

    > CC arch/ia64/kernel/asm-offsets.s
    > In file included from include/linux/smp.h:30,
    > from include/linux/sched.h:68,
    > from arch/ia64/kernel/asm-offsets.c:9:
    > arch/ia64/include/asm/smp.h:60: error: expected ')' before '*' token
    > arch/ia64/include/asm/smp.h:60: error: expected ')' before 'cpu_online_mask'


    Fix is trivial ... delete the declaration of cpu_online_map from
    arch/ia64/include/asm/smp.h

    -Tony
    --
    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/

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4