[PATCH 0/3] x86: add cpus_scnprintf function v3 - Kernel

This is a discussion on [PATCH 0/3] x86: add cpus_scnprintf function v3 - Kernel ; On Wed, Apr 09, 2008 at 01:59:39PM -0700, Mike Travis wrote: > Greg KH wrote: > > On Wed, Apr 09, 2008 at 07:51:23PM +0200, Bert Wesarg wrote: > >> On Tue, Apr 8, 2008 at 8:43 PM, Mike Travis ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 41

Thread: [PATCH 0/3] x86: add cpus_scnprintf function v3

  1. Re: [PATCH 0/3] x86: add cpus_scnprintf function v3

    On Wed, Apr 09, 2008 at 01:59:39PM -0700, Mike Travis wrote:
    > Greg KH wrote:
    > > On Wed, Apr 09, 2008 at 07:51:23PM +0200, Bert Wesarg wrote:
    > >> On Tue, Apr 8, 2008 at 8:43 PM, Mike Travis wrote:
    > >>> * Cleanup usages of cpumask_scprintf in the following files and add
    > >>> another interface to use cpulist_scnprintf where appropriate.
    > >> On Mon, Apr 7, 2008 at 8:22 PM, Mike Travis wrote:
    > >>> 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.
    > >> Btw, I think you can now push for a deprecation of the 'old' mask
    > >> attributes, with the justification you have given above. The other
    > >> possibility is to change sysfs to provide bigger attribute buffers
    > >> (CCed Greg for this).

    > >
    > > Huh?
    > >
    > > sysfs is "one value per file", if you are getting close to PAGE_SIZE in
    > > any sysfs file, then you are doing something very wrong.
    > >
    > > What sysfs file currently is trying to output data this big?
    > >
    > > thanks,
    > >
    > > greg k-h

    >
    > Hi Greg,
    >
    > There's none at the moment. The increase is coming from printing the
    > cpuset for various attributes, like cpus on a node, etc. Since it uses
    > cpumask_scnprintf(), this prints a bit map representing a cpumask_t.
    >
    > With the increase to 4096 cpus, this string is now 1152 bytes long. The
    > next iteration will have 16384 cpus which will need 4608 bytes to fully
    > display, overflowing a standard page. I've added alternate interfaces
    > that use cpulist_scnprintf() which has the advantage of collapsing the
    > bits into ranges. This though can result in a much larger output size
    > if, for example only every other bit is set.
    >
    > Btw, where does one value per file come from?


    Documentation/filesystems/sysfs.txt, while a bit outdated, still
    contains this rule.

    > I see outputs like:
    >
    > # cat /proc/self/stat
    > 4313 (cat) R 4218 4313 4218 34816 4313 4194304 207 0 0 0 0 0 0 0 20 0 1 0 6802916 5672960 131 18446744073709551615 4194304 4212948 140735962676160 18446744073709551615 140499600349840 0 0 0 0 0 0 0 17 3 0 0 0 0 0


    That's fine, it's /proc/, not /sys/

    thanks,

    greg k-h
    --
    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/3] x86: add cpus_scnprintf function v3

    On Wed, Apr 09, 2008 at 10:52:58PM +0200, Bert Wesarg wrote:
    > On Wed, Apr 9, 2008 at 10:39 PM, Greg KH wrote:
    > >
    > > On Wed, Apr 09, 2008 at 07:51:23PM +0200, Bert Wesarg wrote:
    > > > On Tue, Apr 8, 2008 at 8:43 PM, Mike Travis wrote:
    > > > > * Cleanup usages of cpumask_scprintf in the following files and add
    > > > > another interface to use cpulist_scnprintf where appropriate.
    > > >
    > > > On Mon, Apr 7, 2008 at 8:22 PM, Mike Travis wrote:
    > > > > 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.
    > > >
    > > > Btw, I think you can now push for a deprecation of the 'old' mask
    > > > attributes, with the justification you have given above. The other
    > > > possibility is to change sysfs to provide bigger attribute buffers
    > > > (CCed Greg for this).

    > >
    > > Huh?
    > >
    > > sysfs is "one value per file", if you are getting close to PAGE_SIZE in
    > > any sysfs file, then you are doing something very wrong.
    > >
    > > What sysfs file currently is trying to output data this big?

    > Currently none. But if NR_CPUS >= 16K and PAGE_SIZE == 4K, than any
    > file with an cpumask_scnprintf().


    Do we have such sysfs files today?

    thanks,

    greg k-h
    --
    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/3] x86: add cpus_scnprintf function v3

    On Wed, Apr 9, 2008 at 11:14 PM, Greg KH wrote:
    >
    > On Wed, Apr 09, 2008 at 10:52:58PM +0200, Bert Wesarg wrote:
    > > On Wed, Apr 9, 2008 at 10:39 PM, Greg KH wrote:
    > > >
    > > > On Wed, Apr 09, 2008 at 07:51:23PM +0200, Bert Wesarg wrote:
    > > > > On Tue, Apr 8, 2008 at 8:43 PM, Mike Travis wrote:
    > > > > > * Cleanup usages of cpumask_scprintf in the following files and add
    > > > > > another interface to use cpulist_scnprintf where appropriate.
    > > > >
    > > > > On Mon, Apr 7, 2008 at 8:22 PM, Mike Travis wrote:
    > > > > > 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.
    > > > >
    > > > > Btw, I think you can now push for a deprecation of the 'old' mask
    > > > > attributes, with the justification you have given above. The other
    > > > > possibility is to change sysfs to provide bigger attribute buffers
    > > > > (CCed Greg for this).
    > > >
    > > > Huh?
    > > >
    > > > sysfs is "one value per file", if you are getting close to PAGE_SIZE in
    > > > any sysfs file, then you are doing something very wrong.
    > > >
    > > > What sysfs file currently is trying to output data this big?

    > > Currently none. But if NR_CPUS >= 16K and PAGE_SIZE == 4K, than any
    > > file with an cpumask_scnprintf().

    >
    > Do we have such sysfs files today?

    Files with cpumask_scnprintf()? Sure, the cpu topology exports plenty
    of cpu masks.

    If you ask for files with that big NR_CPUS, than no. We are talking
    only for future scenarios.

    Bert
    >
    > thanks,
    >
    > greg k-h
    >

    --
    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/3] x86: add cpus_scnprintf function v3

    Mike wrote:
    > Btw, where does one value per file come from? I see outputs like:
    > ... /proc/self/stat


    The one value per file rule comes in part from files such as this
    stat file. We've been learning the hard way that complex ascii file
    formats tend to be a pain to parse, and a pain to evolve. So we're
    trying to do better in future files. Greg K-H has been especially
    clear on the need to do this in /sys files. We can't change the format
    of old files very well, but we can do better with new files we add.
    The one most common exception to this rule that I find persuasive is
    for a vector of values of the same type and semantics.

    --
    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 3/3] cpumask: add show cpu map functions v2

    Bert wrote:
    > PS: this is the only source I found for the libbitmask(3):


    Mike has been mentioning libbitmask as if it were readily
    available outside SGI. That's not entirely true, yet.

    SGI delivers libbitmask as part of its products to its
    customers under an LGPL license, and I provide libbitmask
    sources to others on request. Real Soon Now (tm) I will
    be publishing libbitmask sources on our oss.sgi.com web
    site for one and all to make use of, under LGPL license.
    But I haven't done that ... yet.

    Libbitmask is a user level library, similar in purpose to,
    but quite different in internal implementation and API
    details from, the bitmap, cpumask and nodemask types in
    the kernel.

    A second library, libcpuset, is also delivered by SGI under
    LGPL license, and provides a rich C library for use by
    major applications requiring a robust cpuset interface.
    This library too should become more easily obtained, once
    I get around to publishing it on oss.sgi.com.

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

  6. Re: [PATCH 2/3] cpumask: use new cpus_scnprintf function v3

    Mike wrote:
    > added new cpulist_scnprintf() interfaces where appropriate.


    Nice - thanks.

    When I get off vacation tomorrow, I will try to review this
    more closely. However I definitely approve of the idea of
    the separate, list formatted, /sys and /proc files.

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

  7. Re: [PATCH 3/3] cpumask: add show cpu map functions v2

    On Thu, Apr 10, 2008 at 2:29 AM, Paul Jackson wrote:
    > Bert wrote:
    > > PS: this is the only source I found for the libbitmask(3):

    >
    > Mike has been mentioning libbitmask as if it were readily
    > available outside SGI. That's not entirely true, yet.
    >
    > SGI delivers libbitmask as part of its products to its
    > customers under an LGPL license, and I provide libbitmask
    > sources to others on request. Real Soon Now (tm) I will
    > be publishing libbitmask sources on our oss.sgi.com web
    > site for one and all to make use of, under LGPL license.
    > But I haven't done that ... yet.
    >
    > Libbitmask is a user level library, similar in purpose to,
    > but quite different in internal implementation and API
    > details from, the bitmap, cpumask and nodemask types in
    > the kernel.
    >
    > A second library, libcpuset, is also delivered by SGI under
    > LGPL license, and provides a rich C library for use by
    > major applications requiring a robust cpuset interface.
    > This library too should become more easily obtained, once
    > I get around to publishing it on oss.sgi.com.

    Thank you for this information.

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

  8. Re: [PATCH 2/3] cpumask: use new cpus_scnprintf function v3

    Mike wrote:
    > added new cpulist_scnprintf() interfaces where appropriate.


    Mike - could you actually list the new *list files added
    by this patch? I suspect that you can start with the
    private email I sent you analyzing v2 of this patch to
    obtain such a list. If we're going to add some new /proc
    and /sys files, we should list them, explicitly, by name,
    and not just wave our hands with a "where appropriate."

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

  9. Re: [PATCH 0/3] x86: add cpus_scnprintf function v3

    Mike wrote:
    > 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.)


    Bert wrote:
    > Btw, I think you can now push for a deprecation of the 'old' mask
    > attributes, with the justification you have given above. The other
    > possibility is to change sysfs to provide bigger attribute buffers
    > (CCed Greg for this).


    Note what Mike said -- some pathological cases will overflow the range
    (what I call "list") format as well.

    Indeed, the worst case "list" format is worse than the worst case "mask"
    format. Masks take a constant 9 chars per 32 bits, or 9/32 chars/bit.

    Worst case lists involve every other CPU or node (all the even ones, or
    all the odd ones.) For CPUs or Nodes that take five decimal digits
    (10000 to 65535 -- some of these are u16 kernel types internall) this
    amounts to 6 chars every 2 possible values, or 3 chars/bit, which is
    quite a bit more than 9/32 chars/bit.

    For example, the list of odd CPUs from 1 to 65535 takes 191053
    characters:

    1,3,5,7,9,11,13,15,17,19,...,65517,65519,65521,655 23,65525,65527,65529,65531,65533,65535

    This will overflow any ordinary page size. The corresponding mask
    takes only 18432 characters:

    AAAAAAAA,AAAAAAAA,AAAAAAAA,AAAAAAAA,AAAAAAAA,AAAAA AAA,...

    Deprecating the mask in favor of the list on account of the
    mask not fitting makes little sense to me, because worst case,
    the list is even bigger .

    Granted, the above examples consider the extreme case of
    NR_CPUS == 65536 or some such. But, as Mike notes, NR_CPUS
    of 16384 might be needed; and the above quandry still applies
    in that case.

    Hmmm ... there are even more pathological list cases. Take two
    out of every three (drop those congruent to 0 mod 3):

    1,2,4,5,7,8,10,11,13,14,...,65521,65522,65524,6552 5,65527,65528,65530,65531,65533,65534

    This requires 254736 characters .

    Even for less insane values, of say two out of three CPUs when
    NR_CPUS == 4096, it takes 12912 characters:

    1,2,4,5,7,8,10,11,13,14,...,4082,4084,4085,4087,40 88,4090,4091,4093,4094

    Whereas the mask format for 4096 NR_CPUS takes just 1152 characters.

    On a system with 4K page size, the above two out of three list would
    not actually show as that 12912 character string. With the current
    code, it would show as a 4094 character string, plus the trailing
    newline and nul char, ending with (if I did my math right):

    ,1436,1438,1439,1441,1442,1444,1445,1447,1448,14

    This is obviously not perfect from an ideal perspective.

    However, I can't see that these pathological cases are enough of a
    practical problem that we should actually spend code addressing them
    at present.

    On the other hand, and my main point of this message, I can't
    see deprecating the mask format files on account of this sort
    of analysis.

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

  10. Re: [PATCH 2/3] cpumask: use new cpus_scnprintf function v3

    Bert, responding to Mike:
    > > It's printing the number of cpus on a node, so the number of nodes is not
    > > important, it's how many cpus can fit on the head of a node... ;-)

    > Ahh, the old code was Just Plain Wrong.


    Looks like the code originally had NR_CPUS, and that was changed to
    MAX_NUMNODES, perhaps as unintended collateral damage from some
    x86_64 node SLIT changes done in the patch:

    http://www.kernel.org/pub/linux/kern...it-sysfs.patch

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

  11. Re: [PATCH 1/3] x86: modify show_shared_cpu_map in intel_cacheinfo v3

    Mike wrote:
    + n = type?
    + cpulist_scnprintf(buf, len-2, *mask):
    + cpumask_scnprintf(buf, len-2, *mask);

    I suspect most of us would find the following variant easier to read:

    if (type)
    n = cpulist_scnprintf(buf, len - 2, *mask);
    else
    n = cpumask_scnprintf(buf, len - 2, *mask);


    Then, going further, the rather too vague "type" parameter name,
    without comment and taking just bare constant values 0 or 1, seems
    more opaque than necessary.

    I can imagine this being easier to read as something like:


    typedef enum { print_as_mask, print_as_list } map_printer_t;

    static ssize_t show_shared_cpu_map_func(struct _cpuid4_info *this_leaf,
    map_printer_t mpt, char *buf)
    {
    ptrdiff_t len = PTR_ALIGN(buf + PAGE_SIZE - 1, PAGE_SIZE) - buf;
    int n = 0;

    if (len > 1) {
    cpumask_t *mask = &this_leaf->shared_cpu_map;

    if (mpt == print_as_mask)
    n = cpumask_scnprintf(buf, len - 2, *mask);
    else
    n = cpulist_scnprintf(buf, len - 2, *mask);
    buf[n++] = '\n';
    buf[n] = '\0';
    }
    return n;
    }

    static inline ssize_t show_shared_cpu_map(struct _cpuid4_info *leaf, char *buf)
    {
    return show_shared_cpu_map_func(leaf, print_as_mask, buf);
    }

    static inline ssize_t show_shared_cpu_list(struct _cpuid4_info *leaf, char *buf)
    {
    return show_shared_cpu_map_func(leaf, print_as_list, buf);
    }



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

  12. Re: [PATCH 1/3] x86: modify show_shared_cpu_map in intel_cacheinfo v3

    Mike, in response to a suggestion from Bert, wrote:
    > I have to subvert the cpumask interface a bit, but the resultant
    > code size is about 7 instructions smaller.


    I should have read ahead to this discussion, before responding
    a minute ago with my suggestion using:

    typedef enum { print_as_mask, print_as_list } map_printer_t;

    I slightly dislike the subversion of the cpumask interface,
    and slightly -do- like the 7 instructions saved.

    Either of these variants (my typedef or Berts function pointer)
    would be fine by me, as you prefer, Mike.

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

  13. Re: [PATCH 2/3] cpumask: use new cpus_scnprintf function v3

    Mike wrote:
    + if (len > 1) {
    + n = type?
    + cpulist_scnprintf(buf, len-2, *mask):
    + cpumask_scnprintf(buf, len-2, *mask);

    I suppose that the discussion of PATCH 1/3 applies to this code too.

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

  14. Re: [PATCH 3/3] cpumask: add show cpu map functions v2

    Mike wrote:
    > * Add cpu_sysdev_class functions to display the following maps
    > with cpulist_scnprintf().


    Nice - thanks.

    Reviewed-by: Paul Jackson

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

  15. Re: [PATCH 0/3] x86: add cpus_scnprintf function v3

    Mike wrote:
    > I agree though sometimes "acceptance" is the hardest part... ;-)


    For changes that would have changed several kernel interfaces
    incompatibly, the bar of acceptance should be higher than for
    changes that only affect kernel internals.

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

  16. Re: [PATCH 0/3] x86: add cpus_scnprintf function v3

    On Thu, Apr 10, 2008 at 2:10 PM, Paul Jackson wrote:
    > Bert wrote:
    > > Btw, I think you can now push for a deprecation of the 'old' mask
    > > attributes, with the justification you have given above. The other
    > > possibility is to change sysfs to provide bigger attribute buffers
    > > (CCed Greg for this).

    >
    > On the other hand, and my main point of this message, I can't
    > see deprecating the mask format files on account of this sort
    > of analysis.
    >

    My statement from above doesn't reflect my opinion. I'm still in
    flavor with the mask output. And from this discussion, I found a new
    point for the mask output: its bounded ;-)

    I just wanted to note, that these new list attributes would be the
    only way to 'change' the api, ie. introduce a new api and deprecate
    the old one, and not change the format of the present api.

    Unfortunately, to support the mask attributes beyond 4k cpus, sysfs
    has to support greater attribute buffers.

    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/

  17. Re: [PATCH 0/3] x86: add cpus_scnprintf function v3

    Bert wrote:
    > My statement from above doesn't reflect my opinion. I'm still in
    > flavor with the mask output. And from this discussion, I found a new
    > point for the mask output: its bounded ;-)


    Ok

    > I just wanted to note, that these new list attributes would be the
    > only way to 'change' the api, ie. introduce a new api and deprecate
    > the old one, and not change the format of the present api.


    Agreed

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

  18. Re: [PATCH 1/3] x86: modify show_shared_cpu_map in intel_cacheinfo v3

    On Tue, Apr 8, 2008 at 10:44 PM, Mike Travis wrote:
    > Btw, you were asking about how to determine NR_CPUS. Here's one way:
    >
    > root@newton:~# cat /sys/devices/system/cpu/online
    > 0-2,4-7
    > root@newton:~# cat /sys/devices/system/cpu/possible
    > 0-511
    > root@newton:~# cat /sys/devices/system/cpu/present
    > 0-7
    > root@newton:~# cat /sys/devices/system/cpu/system
    > 0-4095

    I think its easier to count the commas from a cpumask file. Here you
    must parse a complete list expression, just to get the max id.

    Either way, I think this isn't a very clean way.

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

  19. Re: [PATCH 0/3] x86: add cpus_scnprintf function v3

    On Thu, Apr 10, 2008 at 7:30 PM, Greg KH wrote:
    >
    > On Thu, Apr 10, 2008 at 06:14:55PM +0200, Bert Wesarg wrote:
    > > On Thu, Apr 10, 2008 at 2:10 PM, Paul Jackson wrote:
    > > > Bert wrote:
    > > > > Btw, I think you can now push for a deprecation of the 'old' mask
    > > > > attributes, with the justification you have given above. The other
    > > > > possibility is to change sysfs to provide bigger attribute buffers
    > > > > (CCed Greg for this).
    > > >
    > > > On the other hand, and my main point of this message, I can't
    > > > see deprecating the mask format files on account of this sort
    > > > of analysis.
    > > >

    > > My statement from above doesn't reflect my opinion. I'm still in
    > > flavor with the mask output. And from this discussion, I found a new
    > > point for the mask output: its bounded ;-)
    > >
    > > I just wanted to note, that these new list attributes would be the
    > > only way to 'change' the api, ie. introduce a new api and deprecate
    > > the old one, and not change the format of the present api.
    > >
    > > Unfortunately, to support the mask attributes beyond 4k cpus, sysfs
    > > has to support greater attribute buffers.

    >
    > Well, it does already today, you just have to work at it
    >
    > What we can do for these types of files, is to use the "binary
    > attribute" file format. With that, you get full control over the buffer
    > size and other operations.
    >
    > So someone should just wrap up the cpu mask sysfs file usage in a
    > function that uses the binary attribute instead. Then everyone who uses
    > the cpu mask in a sysfs file can use that function instead.
    >
    > Sound reasonable?

    Very. Thanks.

    Bert
    >
    > thanks,
    >
    > greg k-h
    >

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

  20. Re: [PATCH 1/3] x86: modify show_shared_cpu_map in intel_cacheinfo v3

    Bert wrote:
    > I think its easier to count the commas from a cpumask file.


    My user level code determines NR_CPUS and MAX_NUMNODES from 32/9 times
    the strlen() of the values of the Cpus_allowed and Mems_allowed fields
    in /proc/self/status (being careful to -include- the trailing newline
    in the strlen.)

    --
    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
Page 2 of 3 FirstFirst 1 2 3 LastLast