[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <488E06F0.4070404@sgi.com>
Date: Mon, 28 Jul 2008 10:50:40 -0700
From: Mike Travis <travis@....com>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] cpus4096 fixes
Rusty Russell wrote:
> On Monday 28 July 2008 06:15:26 Linus Torvalds wrote:
>> On Sun, 27 Jul 2008, Ingo Molnar wrote:
>>> Please pull the latest cpus4096-fixes git tree from:
>> No. Not without explanations.
>>
>> Quite frankly, this "fix" looks like a huge stinking pile of sh*t.
>>
>> I can't follow that thread on lkml.org (horrible web interface with
>> hard-to-follow threading), and I'm too lazy to bother to look in my lkml
>> email archives, but whoever said
>>
>> "The simple version is just a static array of [NR_CPUS] cpumask_t's."
>>
>> and then implemented this piece of shit is a complete and utter moron.
>
> How awesome, Linus is talking about me!
>
> Your idea is clever, thanks. This patch was a bandaid to save us from the
> unbearably fugly "cpumask_of_cpu_ptr_declare(cpu_mask)". I was going to rip
> this code out as soon as possible, but with your trick we should keep it.
>
> The 4k CPU patches have been sliding in without review up until now. We need
> a serious think about how to handle cpumask_t that doesn't fit on the stack.
>
> Hey, since Mike put his Signed-off-by above mine and didn't put a From line
> when he took my patch, WFT am I taking responsibility? :)
>
> Rusty.
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.
But I'll redo the patch again. And look for more space saving areas. As
for the goal of these patches, it was to lessen the impact as much as possible
on smaller systems so that the distros can set the default NR_CPUS=4096 in
their binary (validated, certified, licensable) kernels. This is a huge
priority to our customers. Please keep telling me where I'm going wrong at
this.
Thanks for the comments and feedback.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists