From: Mike Travis <travis@sgi.com>
To: Greg KH <gregkh@suse.de>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>,
Ingo Molnar <mingo@elte.hu>, Paul Jackson <pj@sgi.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] x86: add cpus_scnprintf function v3
Date: Wed, 09 Apr 2008 13:59:39 -0700 [thread overview]
Message-ID: <47FD2E3B.5010801@sgi.com> (raw)
In-Reply-To: <20080409203909.GA17183@suse.de>
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 <travis@sgi.com> 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 <travis@sgi.com> 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? 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
Thanks,
Mike
next prev parent reply other threads:[~2008-04-09 20:59 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-08 18:43 [PATCH 0/3] x86: add cpus_scnprintf function v3 Mike Travis
2008-04-08 18:43 ` [PATCH 1/3] x86: modify show_shared_cpu_map in intel_cacheinfo v3 Mike Travis
2008-04-08 19:36 ` Bert Wesarg
2008-04-08 20:44 ` Mike Travis
2008-04-10 14:03 ` Paul Jackson
2008-04-10 17:24 ` Bert Wesarg
2008-04-10 17:36 ` Paul Jackson
2008-04-10 13:57 ` Paul Jackson
2008-04-08 18:43 ` [PATCH 2/3] cpumask: use new cpus_scnprintf function v3 Mike Travis
2008-04-08 19:40 ` Bert Wesarg
2008-04-08 20:46 ` Mike Travis
2008-04-09 15:53 ` Bert Wesarg
2008-04-10 12:49 ` Paul Jackson
2008-04-10 0:32 ` Paul Jackson
2008-04-10 12:13 ` Paul Jackson
2008-04-10 14:05 ` Paul Jackson
2008-04-08 18:43 ` [PATCH 3/3] cpumask: add show cpu map functions v2 Mike Travis
2008-04-08 19:32 ` Bert Wesarg
2008-04-08 20:52 ` Mike Travis
2008-04-09 17:39 ` Bert Wesarg
2008-04-10 0:29 ` Paul Jackson
2008-04-10 6:05 ` Bert Wesarg
2008-04-10 14:13 ` Paul Jackson
2008-04-08 19:33 ` [PATCH 0/3] x86: add cpus_scnprintf function v3 Bert Wesarg
2008-04-08 20:54 ` Mike Travis
2008-04-10 15:03 ` Paul Jackson
2008-04-09 15:11 ` Ingo Molnar
2008-04-09 17:51 ` Bert Wesarg
2008-04-09 20:39 ` Greg KH
2008-04-09 20:52 ` Bert Wesarg
2008-04-09 21:14 ` Greg KH
2008-04-09 21:21 ` Bert Wesarg
2008-04-09 20:59 ` Mike Travis [this message]
2008-04-09 21:02 ` Bert Wesarg
2008-04-09 21:15 ` Greg KH
2008-04-10 0:18 ` Paul Jackson
2008-04-10 12:10 ` Paul Jackson
2008-04-10 16:14 ` Bert Wesarg
2008-04-10 16:27 ` Paul Jackson
2008-04-10 17:30 ` Greg KH
2008-04-10 17:36 ` Bert Wesarg
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=47FD2E3B.5010801@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=bert.wesarg@googlemail.com \
--cc=gregkh@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.