From: David Mosberger <davidm@napali.hpl.hp.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: <alan@lxorguk.ukuu.org.uk>, <davidm@hpl.hp.com>,
<akpm@zip.com.au>, <linux-kernel@vger.kernel.org>
Subject: Re: proc_misc.c bug
Date: Thu, 10 Apr 2003 22:41:23 -0700 [thread overview]
Message-ID: <16022.21891.554860.506152@napali.hpl.hp.com> (raw)
In-Reply-To: <32880.4.64.197.106.1050037303.squirrel@webmail.osdl.org>
>>>>> On Thu, 10 Apr 2003 22:01:43 -0700 (PDT), "Randy.Dunlap" <rddunlap@osdl.org> said:
Randy> OK, I've looked at it and concluded that it's not bad the way
Randy> it is (after David's patch is applied). However, that really
Randy> depends on whether the static NR_CPUS is well-tuned or not.
Randy> If it's not tuned, then modifying the output to use the
Randy> iterative seq_file methods would make sense. But if it's not
Randy> tuned, someone is (usually) wasting lots of memory anyway.
Randy> [snip...]
Randy> Does someone want to disagree now? go ahead...i'm listening.
Randy> Maybe the reason to modify it is that NR_CPUS is not a good
Randy> approximation/hint/clue.
Wouldn't the kmalloc() likely fail in fragmented conditions? Also,
I'm wondering whether there is such a thing as "well-tuned" in this
case. For example, in the extreme case of the SGI SN2 machine, each
CPU could in theory have up to 256 interrupt sources (OK, perhaps it's
only 256 interrupts per 2 CPUs, but it's still a lot of interrupts to
go around ;-). OTOH, most ia64 machines out there have less than 256
interrupt per _system_. That's a large variation.
--david
next prev parent reply other threads:[~2003-04-11 5:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-10 22:02 proc_misc.c bug David Mosberger
2003-04-10 21:44 ` Alan Cox
2003-04-10 22:49 ` Randy.Dunlap
2003-04-11 5:01 ` Randy.Dunlap
2003-04-11 5:28 ` Andrew Morton
2003-04-11 5:41 ` David Mosberger [this message]
2003-04-11 5:46 ` Zwane Mwaikambo
2003-04-11 17:29 ` Randy.Dunlap
2003-04-11 18:32 ` David Mosberger
2003-04-10 22:53 ` Andrew Morton
2003-04-11 0:27 ` David Mosberger
2003-04-10 22:18 ` Andrew Morton
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=16022.21891.554860.506152@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=akpm@zip.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davidm@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@osdl.org \
/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;
as well as URLs for NNTP newsgroup(s).