Messages in this thread | | | Date | Mon, 31 Mar 2008 09:35:09 -0700 | From | Mike Travis <> | Subject | Re: [PATCH 2/2] x86: modify show_shared_cpu_map in intel_cacheinfo |
| |
Bert Wesarg wrote: > On Fri, Mar 28, 2008 at 7:19 PM, Mike Travis <travis@sgi.com> wrote: >> > Aren't the most cpumaps (like cpu/cpu*/topology/*_siblings or >> > node/node*/cpumap) bitmasks? >> >> I did an informal survey and you are right, the majority of references do use >> cpumask_scnprintf instead of cpulist_scnprintf. Maybe the later function was >> added later? >> >> To me though, it would seem that: >> >> 240-255 >> >> is more readable than: >> >> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000ffff >> >> And as I mentioned, bitmask_parselist() [libbitmask(3)] does parse the output. > But libbitmask has a bitmask_parsehex() too. (but thanks for the > pointer to this code). > > Anyway, your above example is wrong, the most significant bits comes first: > > ffff0000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > > This makes it not more readable, but I think readability isn't in this > case of that much importance.
The original problem was how to avoid allocating a large stack space to display cpu ids. By using cpulist_scnprintf, it accomplishes this without, what I think is too much pain. If it's really that much of a problem, I will rework this patch. But the length of the line with 4096 cpus will be 1152 bytes Is this really better?
> > I further think, this problem could be easily solved, if NR_CPUS and > possibly your nr_cpus_ids is somehow exported to user space. > > With this information, the user is not surprised to see more that 1024 > bits (=CPU_SETSIZE, which is currently the glibc constant for the > sched_{set,get}affinity() API). Also the glibc has the new variable > cpu_set_t size API (since 2.7).
Yes, thanks. That is being dealt with in another task.
Thanks, Mike
| |