public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Bert Wesarg <bert.wesarg@googlemail.com>
Cc: Ingo Molnar <mingo@elte.hu>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] x86: modify show_shared_cpu_map in intel_cacheinfo
Date: Fri, 28 Mar 2008 07:40:03 -0700	[thread overview]
Message-ID: <47ED0343.1070708@sgi.com> (raw)
In-Reply-To: <36ca99e90803280201i708ce9b7y293a2c68e733f088@mail.gmail.com>

Bert Wesarg wrote:
> On Fri, Mar 28, 2008 at 12:16 AM, Mike Travis <travis@sgi.com> wrote:
>> Used cpulist_scnprintf to print cpus on a leaf instead of requiring
>>  a new "cpumask_scnprintf_len" function to determine the size of
>>  the temporary buffer.  cpulist_scnprintf can be used to print directly
>>  to the output buffer, eliminating the need for the temporary buffer.
>>
>>  Based on:
>>         git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>         git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>>
>>  Signed-off-by: Mike Travis <travis@sgi.com>
>>  ---
>>   arch/x86/kernel/cpu/intel_cacheinfo.c |   25 +++++++++++++++++--------
>>   1 file changed, 17 insertions(+), 8 deletions(-)
>>
>>  --- linux.trees.git.orig/arch/x86/kernel/cpu/intel_cacheinfo.c
>>  +++ linux.trees.git/arch/x86/kernel/cpu/intel_cacheinfo.c
>>  @@ -593,14 +593,23 @@ static ssize_t show_size(struct _cpuid4_
>>
>>   static ssize_t show_shared_cpu_map(struct _cpuid4_info *this_leaf, char *buf)
>>   {
>>  -       int n = 0;
>>  -       int len = cpumask_scnprintf_len(nr_cpu_ids);
>>  -       char *mask_str = kmalloc(len, GFP_KERNEL);
>>  -
>>  -       if (mask_str) {
>>  -               cpumask_scnprintf(mask_str, len, this_leaf->shared_cpu_map);
>>  -               n = sprintf(buf, "%s\n", mask_str);
>>  -               kfree(mask_str);
>>  +       /*
>>  +        * cpulist_scnprintf() has the advantage of compressing
>>  +        * consecutive cpu numbers into a single range which seems
>>  +        * appropriate for cpus on a leaf.  This will change what is
>>  +        * output so scripts that process the output will have to change.
> So this breaks user space?
> 
> Bert

Potentially, yes.  But I suspect with 4096 cpus, user scripts will have
to change anyways.  Currently it is represented as sets of 32 bit mask
outputs with comma separators, so 1152 characters would be output.

Is there a special notice I should provide to announce this change?

(And this output does conform with other syntax for printing and parsing
strings of bits.)

Thanks,
Mike

  reply	other threads:[~2008-03-28 14:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 23:16 [PATCH 0/2] x86: add functions in preparation of cpumask changes Mike Travis
2008-03-27 23:16 ` [PATCH 1/2] x86: Convert cpumask_of_cpu macro to allocated array Mike Travis
2008-03-27 23:16 ` [PATCH 2/2] x86: modify show_shared_cpu_map in intel_cacheinfo Mike Travis
2008-03-28  9:01   ` Bert Wesarg
2008-03-28 14:40     ` Mike Travis [this message]
2008-03-28 14:54       ` Bert Wesarg
2008-03-28 18:19         ` Mike Travis
2008-03-29  8:59           ` Bert Wesarg
2008-03-31 16:35             ` Mike Travis
2008-03-31 17:24               ` Bert Wesarg
2008-03-31 18:18                 ` Paul Jackson
2008-03-31 17:56               ` Paul Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47ED0343.1070708@sgi.com \
    --to=travis@sgi.com \
    --cc=bert.wesarg@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox