From: Mike Travis <travis@sgi.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [git pull] cpus4096 fixes
Date: Mon, 28 Jul 2008 12:04:38 -0700 [thread overview]
Message-ID: <488E1846.3030307@sgi.com> (raw)
In-Reply-To: <alpine.LFD.1.10.0807281127150.3486@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> On Mon, 28 Jul 2008, Mike Travis wrote:
>> Sorry, I didn't know that was the protocol. And yes, the clever idea of
>> compacting the memory is a good one (wish I would have thought of it... ;-)
>> But, and it's a big but, if you really have 4096 cpus present (not NR_CPUS,
>> but nr_cpu_ids), then 2MB is pretty much chump change.
>
> Umm. Yes, it's chump change, but if you compile a kernel to be generic,
> and you actually only have a few CPU's, it's no longer chump change.
The 2Mb's of initdata is released, I just meant that if you really have 4k
cpus in the system, you'll probably have 4k * [2 .. 32 Gb (or more?)] of
memory. The Nahalem memory limit is (iirc) 44 bits.
Originally, I only had the constant for cpu(0) but since it _was_ originally
a constant (alibi, rvalue only), then it might be thought that it's valid to
use any cpu# before setup_per_cpu_areas is called.
>
>> But I'll redo the patch again.
>
> Here's a trivial setup, that is even tested. It's _small_ too.
>
> /* cpu_bit_bitmap[0] is empty - so we can back into it */
> #define MASK_DECLARE_1(x) [x+1][0] = 1ul << (x)
> #define MASK_DECLARE_2(x) MASK_DECLARE_1(x), MASK_DECLARE_1(x+1)
> #define MASK_DECLARE_4(x) MASK_DECLARE_2(x), MASK_DECLARE_2(x+2)
> #define MASK_DECLARE_8(x) MASK_DECLARE_4(x), MASK_DECLARE_4(x+4)
>
> static const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = {
> MASK_DECLARE_8(0), MASK_DECLARE_8(8),
> MASK_DECLARE_8(16), MASK_DECLARE_8(24),
> #if BITS_PER_LONG > 32
> MASK_DECLARE_8(32), MASK_DECLARE_8(40),
> MASK_DECLARE_8(48), MASK_DECLARE_8(56),
> #endif
> };
>
> static inline const cpumask_t *get_cpu_mask(unsigned int nr)
> {
> const unsigned long *p = cpu_bit_bitmap[1 + nr % BITS_PER_LONG];
> p -= nr / BITS_PER_LONG;
> return (const cpumask_t *)p;
> }
>
> that should be all you need to do.
Very cool, thanks!!
>
> Honesty in advertizing: my "testing" was some trivial user-space harness,
> maybe I had some bug in it. But at least it's not _horribly_ wrong.
>
> And yes, this has the added optimization from Viro of overlapping the
> cpumask_t's internally too, rather than making them twice the size. So
> with 4096 CPU's, this should result 32.5kB of static const data.
>
> Linus
Don't worry, I'll beat it to death... ;-) [and try not to screw up the
acknowledgments this time... ;-)]
Thanks again,
Mike
next prev parent reply other threads:[~2008-07-28 19:04 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-27 19:06 [git pull] cpus4096 fixes Ingo Molnar
2008-07-27 20:15 ` Linus Torvalds
2008-07-27 21:03 ` Ingo Molnar
2008-07-28 18:42 ` Mike Travis
2008-07-27 21:05 ` Al Viro
2008-07-27 22:17 ` Linus Torvalds
2008-07-28 0:42 ` Rusty Russell
2008-07-28 3:06 ` Andrew Morton
2008-07-28 6:34 ` Rusty Russell
2008-07-28 6:58 ` Nick Piggin
2008-07-28 7:56 ` Ingo Molnar
2008-07-28 18:12 ` Mike Travis
2008-07-28 8:33 ` Ingo Molnar
2008-07-28 18:07 ` Mike Travis
2008-07-28 17:50 ` Mike Travis
2008-07-28 18:32 ` Linus Torvalds
2008-07-28 18:37 ` Linus Torvalds
2008-07-28 18:51 ` Ingo Molnar
2008-07-28 19:22 ` Mike Travis
2008-07-28 19:31 ` Mike Travis
2008-07-28 19:04 ` Mike Travis [this message]
2008-07-28 20:57 ` [rfc git pull] cpus4096 fixes, take 2 Ingo Molnar
2008-07-28 21:35 ` Ingo Molnar
2008-07-28 21:41 ` [build error] drivers/char/pcmcia/ipwireless/hardware.c:571: error: invalid use of undefined type 'struct ipw_network' Ingo Molnar
2008-07-28 22:06 ` Ingo Molnar
2008-07-28 22:20 ` Andrew Morton
2008-07-28 22:29 ` Ingo Molnar
2008-07-30 14:59 ` David Sterba
2008-07-30 15:11 ` James Bottomley
2008-07-30 15:14 ` Jiri Kosina
2008-07-28 21:36 ` [rfc git pull] cpus4096 fixes, take 2 Mike Travis
2008-07-29 1:45 ` Rusty Russell
2008-07-29 12:11 ` Ingo Molnar
2008-07-30 0:15 ` Rusty Russell
2008-07-28 18:46 ` [git pull] cpus4096 fixes Mike Travis
2008-07-28 19:13 ` Ingo Molnar
2008-07-29 1:33 ` Rusty Russell
2008-07-28 0:53 ` Rusty Russell
2008-07-28 8:16 ` Ingo Molnar
2008-07-28 13:21 ` Rusty Russell
2008-07-28 18:23 ` Mike Travis
2008-07-31 10:30 ` Ingo Molnar
2008-07-28 8:43 ` Ingo Molnar
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=488E1846.3030307@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.