From: Keith Owens <kaos@ocs.com.au>
To: Russ Weight <rweight@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
LSE Tech <lse-tech@lists.sourceforge.net>
Subject: Re: Static/Global Arrays
Date: Sat, 15 Dec 2001 19:42:10 +1100 [thread overview]
Message-ID: <20332.1008405730@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Fri, 14 Dec 2001 16:31:10 -0800." <20011214163110.A2423@us.ibm.com>
On Fri, 14 Dec 2001 16:31:10 -0800,
Russ Weight <rweight@us.ibm.com> wrote:
> I have tabulated lists of static and global arrays in the
>2.4.16 kernel. I am posting the information here in case it may be
>of interest to some of you. I would recommend starting with the
>linux/kernel and linux/fs tables, as these are the most complete.
>
> http://lse.sourceforge.net/resource/#staticarray
Stating the obvious: For any array with dimension [32] or [64], check
if the source code uses [NR_CPUS]. IMHO there is no point in trying to
make those arrays dynamic in size, you penalize the 99% of small
machines on the off chance that somebody is going to run single system
image Linux on a box with > 32/64 processors. People using such large
machines can recompile the kernel with a new value of NR_CPUS.
As a separate problem, there are still places in the kernel which
assume the number of cpus can be represented in a bitmap of type long.
That code would be worth tracking down and changing to remove the
assumption that NR_CPUS <= 8*sizeof(long). Until that is done, you
cannot run SSI Linux on machines with > 32/64 processors.
Note to self: after the bitmap code limit has been removed, make
NR_CPUS a config option to get ready for huge machines, make
CONFIG_NR_CPUS a critical config option.
prev parent reply other threads:[~2001-12-15 8:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-15 0:31 Static/Global Arrays Russ Weight
2001-12-15 8:42 ` Keith Owens [this message]
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=20332.1008405730@ocs3.intra.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=rweight@us.ibm.com \
/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.