[PATCH 0/4] x86: add cpus_scnprintf function v2 - Kernel

This is a discussion on [PATCH 0/4] x86: add cpus_scnprintf function v2 - Kernel ; * Add a new cpus_scnprintf and a sysctl flag to control how cpumask sets are printed. The default (1) is to use the current cpumask_scnprintf. If kernel.compat_cpus_printf is '0', then cpulist_scnprintf is used. In addition, a nodes_scnprintf function is provided ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: [PATCH 0/4] x86: add cpus_scnprintf function v2

  1. [PATCH 0/4] x86: add cpus_scnprintf function v2


    * Add a new cpus_scnprintf and a sysctl flag to control how cpumask sets
    are printed. The default (1) is to use the current cpumask_scnprintf.
    If kernel.compat_cpus_printf is '0', then cpulist_scnprintf is used.
    In addition, a nodes_scnprintf function is provided for compatibilty.

    * This is introduced with a CONFIG_KERN_COMPAT_CPUSET_PRINTF flag which
    currently is only defined for X86_64_SMP architecture. For all other
    architectures the current cpumask_scnprintf() is used.

    * Add usage information to Documentation/sysctl/kernel.txt for the
    /proc/sys/kernel/compat_cpus_printf flag.

    * Add cpu_sysdev_class functions to display the

    cpu_online_map
    cpu_present_map
    cpu_possible_map
    cpu_system_map

    * Modify usages of cpumask_scnprintf to use the new cpus_scnprintf where
    appropriate. The list of files affected are:

    arch/x86/kernel/cpu/intel_cacheinfo.c
    drivers/base/node.c
    drivers/base/topology.c
    drivers/pci/pci-sysfs.c
    drivers/pci/probe.c
    kernel/irq/proc.c
    kernel/profile.c
    kernel/sched_stats.h
    kernel/sysctl.c
    kernel/sysctl_check.c
    kernel/trace/trace.c

    Note that kernel/sched.c is not in this patchset as it has many other changes,
    so the change to use cpus_scnprintf is in a following patchset.

    For inclusion in x86/latest.

    Based on:
    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    + x86/latest .../x86/linux-2.6-x86.git
    + sched-devel/latest .../mingo/linux-2.6-sched-devel.git

    Signed-off-by: Mike Travis
    ---
    v2:
    Renamed cpuset_scnprintf() to cpus_scnprintf to avoid confusion with
    "cpusets", and changed the other names to match.

    Added a sentinel character for the cpulist type output so scripts can
    be written to handle both cases.

    Added warning in the Documentation/sysctl/kernel.txt that changing this
    option may break scripts and programs that rely on the current format.
    Also provided example on how to process the output.

    Added information to Documentation/scheduler/sched-stats.txt about
    change in version number because of new cpus_scnprintf function.

    --
    --
    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: [PATCH 0/4] x86: add cpus_scnprintf function v2

    I still have some concerns with this cpus_scnprintf patch.

    I've taken them up with Mike offline for initial consideration.

    If others have questions, concerns or enthusiasms for this patch,
    Mike and I would be interested.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson 1.940.382.4214
    --
    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 0/4] x86: add cpus_scnprintf function v2


    * Paul Jackson wrote:

    > I still have some concerns with this cpus_scnprintf patch.
    >
    > I've taken them up with Mike offline for initial consideration.
    >
    > If others have questions, concerns or enthusiasms for this patch, Mike
    > and I would be interested.


    i dont mind the old patch either (which did an ugly temporary
    allocation), if it keeps the ABI. I dont think it's a big deal, lets not
    allow it to become a roadblock, and the overall goal of all these
    patches [4096 CPU support in upstream Linux] is important and i'm
    enthusiastic about that ;-)

    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/

  4. Re: [PATCH 0/4] x86: add cpus_scnprintf function v2

    Ingo wrote:
    > the overall goal of all these patches [4096 CPU
    > support in upstream Linux] is important and i'm
    > enthusiastic about that ;-)


    Yes, the goal is important, and yes Mike has done
    a pile of excellent work meeting that goal.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson 1.940.382.4214
    --
    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: [PATCH 2/4] x86: modify show_shared_cpu_map in intel_cacheinfo v2

    On Sat, Apr 5, 2008 at 3:24 AM, Mike Travis wrote:
    > --- linux-2.6.x86.orig/arch/x86/kernel/cpu/intel_cacheinfo.c
    > +++ linux-2.6.x86/arch/x86/kernel/cpu/intel_cacheinfo.c
    > @@ -593,14 +593,17 @@ static ssize_t show_size(struct _cpuid4_
    >
    > static ssize_t show_shared_cpu_map(struct _cpuid4_info *this_leaf, char *buf)
    > {
    > + unsigned long end = ALIGN((unsigned long)buf, PAGE_SIZE);

    May I suggest this:

    ptrdiff_t len = PTR_ALIGN(buf + PAGE_SIZE - 1, PAGE_SIZE) - buf;

    > + if (len == 0)
    > + len = PAGE_SIZE;

    Than this is not necessary.

    > +
    > + if (len >= 2) {
    > + n = cpus_scnprintf(buf, len-2, this_leaf->shared_cpu_map);
    > + buf[n++] = '\n';
    > + buf[n] = '\0';
    > }
    > return n;
    > }

    Apart from my suggestion and the use of cpus_scnprintf I think this patch is ok.

    Bert

    PS: sorry for the long delay.
    --
    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: [PATCH 0/4] x86: add cpus_scnprintf function v2

    On Mon, Apr 7, 2008 at 10:04 AM, Paul Jackson wrote:
    > I still have some concerns with this cpus_scnprintf patch.
    >
    > I've taken them up with Mike offline for initial consideration.
    >
    > If others have questions, concerns or enthusiasms for this patch,
    > Mike and I would be interested.

    As long as the only justification for this cpus_scnprintf is human
    readability, I have concerns too.

    Patch 2/4 itself is ok and 4/4 too. The only thing I miss is an export
    of NR_CPUS. So that you know in front of reading a kernel mask, what
    size your bitmap needs. (for example glibc cpu_set_t has only 1024
    bits but has an cpu_set_t with arbitrary size too).

    Bert
    --
    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: [PATCH 0/4] x86: add cpus_scnprintf function v2

    Bert Wesarg wrote:
    > On Mon, Apr 7, 2008 at 10:04 AM, Paul Jackson wrote:
    >> I still have some concerns with this cpus_scnprintf patch.
    >>
    >> I've taken them up with Mike offline for initial consideration.
    >>
    >> If others have questions, concerns or enthusiasms for this patch,
    >> Mike and I would be interested.

    > As long as the only justification for this cpus_scnprintf is human
    > readability, I have concerns too.
    >
    > Patch 2/4 itself is ok and 4/4 too. The only thing I miss is an export
    > of NR_CPUS. So that you know in front of reading a kernel mask, what
    > size your bitmap needs. (for example glibc cpu_set_t has only 1024
    > bits but has an cpu_set_t with arbitrary size too).
    >
    > Bert


    Hi Bert,

    Yes, sorry, I promised I'd follow up with you on what's happening. I
    did get some feedback on changes proposed but haven't yet tracked down
    specific details yet.

    Part of the change is readability, but also looking towards the future
    of 16k/64k/??? # of cpus, the straight mask approach will overflow the
    PAGE_SIZE buffer provided (though some pathological cases will overflow
    the range method as well.) So we'll need some advancement in the format
    of the printout.

    Another aspect is that this brings the cpumap and cpuset interfaces
    closer as the latter already uses the range method.

    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/

  8. Re: [PATCH 2/4] x86: modify show_shared_cpu_map in intel_cacheinfo v2

    Bert Wesarg wrote:
    > On Sat, Apr 5, 2008 at 3:24 AM, Mike Travis wrote:
    >> --- linux-2.6.x86.orig/arch/x86/kernel/cpu/intel_cacheinfo.c
    >> +++ linux-2.6.x86/arch/x86/kernel/cpu/intel_cacheinfo.c
    >> @@ -593,14 +593,17 @@ static ssize_t show_size(struct _cpuid4_
    >>
    >> static ssize_t show_shared_cpu_map(struct _cpuid4_info *this_leaf, char *buf)
    >> {
    >> + unsigned long end = ALIGN((unsigned long)buf, PAGE_SIZE);

    > May I suggest this:
    >
    > ptrdiff_t len = PTR_ALIGN(buf + PAGE_SIZE - 1, PAGE_SIZE) - buf;


    Hmm, that sounds great. There were a number of different methods used in
    the various places to provide for that extra '\n'! ;-)

    >
    >> + if (len == 0)
    >> + len = PAGE_SIZE;

    > Than this is not necessary.
    >
    >> +
    >> + if (len >= 2) {
    >> + n = cpus_scnprintf(buf, len-2, this_leaf->shared_cpu_map);
    >> + buf[n++] = '\n';
    >> + buf[n] = '\0';
    >> }
    >> return n;
    >> }

    > Apart from my suggestion and the use of cpus_scnprintf I think this patch is ok.
    >
    > Bert
    >
    > PS: sorry for the long delay.


    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: [PATCH 0/4] x86: add cpus_scnprintf function v2

    Ingo Molnar wrote:
    > * Paul Jackson wrote:
    >
    >> I still have some concerns with this cpus_scnprintf patch.
    >>
    >> I've taken them up with Mike offline for initial consideration.
    >>
    >> If others have questions, concerns or enthusiasms for this patch, Mike
    >> and I would be interested.

    >
    > i dont mind the old patch either (which did an ugly temporary
    > allocation), if it keeps the ABI. I dont think it's a big deal, lets not
    > allow it to become a roadblock, and the overall goal of all these
    > patches [4096 CPU support in upstream Linux] is important and i'm
    > enthusiastic about that ;-)
    >
    > Ingo


    I have no stake in the ground for this either. My assigned task was to
    minimize the effect of bumping up the possible cpu count to a really
    large amount. This seemed to me to fall in this category. A side goal
    was to prepare for even larger cpu count systems.

    An alternative that Paul had suggested was to introduce a new set of
    file interfaces that produce the alternate format. This would not
    break existing interfaces and allow a transition, though how many
    post-processors of the information would change is unclear. Given
    that fact, would the added code and complexity be worthwhile?

    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/

  10. Re: [PATCH 0/4] x86: add cpus_scnprintf function v2

    Ingo, responding to Paul, three days ago:
    > i dont mind the old patch either (which did an ugly temporary
    > allocation), if it keeps the ABI.


    But this v2 and earlier patch versions broke the kernel-user interface,
    incompatibly, for about a dozen different /sys and /proc files, and
    without even stating so very clearly in the patch commentary. We'd
    have to be rather desperate before I'd agree to that.

    Mike's latest v3 version of this cpus_scnprintf patchset has resolved
    these incompatibilities, by adding new *list files in /sys and /proc,
    and new *list line items in the /proc//status files, rather than
    breaking existing files and lines.

    That is much better. Better to add files and lines, than to change the
    format of existing ones.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson 1.940.382.4214
    --
    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