[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FAB1AC9.1050306@gmail.com>
Date: Wed, 09 May 2012 21:32:57 -0400
From: KOSAKI Motohiro <kosaki.motohiro@...il.com>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
LKML <linux-kernel@...r.kernel.org>, anton@...ba.org,
Arnd Bergmann <arnd@...db.de>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Mike Travis <travis@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>, kosaki.motohiro@...il.com
Subject: Re: [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK.
(5/9/12 2:10 AM), Rusty Russell wrote:
> Hi Ingo,
>
> I finally rebased this on top of your tip tree, and tested it
> locally. Some more old-style cpumask usages have crept in, but it's a
> fairly simple series.
>
> The final result is that if you enable CONFIG_CPUMASK_OFFSTACK, then
> 'struct cpumask' becomes an undefined type. You can't accidentally take
> the size of it, assign it, or pass it by value. And thus it's safe for
> us to make it smaller if nr_cpu_ids< NR_CPUS, as the final patch does.
>
> It unfortunately requires the lglock cleanup patch, which Al already has
> queued, so I've included it here.
Hi
Thanks this effort. This is very cleaner than I expected.
However I should NAK following one patch. sorry. because of, lru-drain is
called from memory reclaim context. It mean, additional allocation may not
work. Please just use bare NR_CPUS bitmap instead. space wasting is minor
issue than that.
> commit fab26054c0500d426cf1bc2ce227a6a428dc815e
> Author: Rusty Russell<rusty@...tcorp.com.au>
> Date: Wed May 9 14:55:15 2012 +0930
>
> page_alloc: use cpumask_var_t.
>
> The BSS trick works, but it still wastes space. Especially since there's
> a nice fallback in the case where we fail to allocate a temporary cpumask.
>
> Signed-off-by: Rusty Russell<rusty@...tcorp.com.au>
Other patches looks very goold.
Acked-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Thanks.
--
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