[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4A0AD0D3.6030802@novell.com>
Date: Wed, 13 May 2009 22:53:23 +0900
From: Tejun Heo <teheo@...ell.com>
To: Jan Beulich <JBeulich@...ell.com>
Cc: Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
linux-kernel@...r.kernel.org
Subject: Re: remap allocator for per-CPU memory
Hello, Jan.
Jan Beulich wrote:
>>>> Tejun Heo <teheo@...ell.com> 13.05.09 15:29 >>>
>>> (b) teach the pageattr code to handle the per-CPU virtual area similarly to
>>> the kernel space for x86-64 (though it's going to be a little more complicated
>>> since there's no pre-determined relation between the virtual and physical
>>> addresses - the necessary lookup might become expensive on systems with
>>> very many [possible] CPUs).
>> Can you elaborate this a bit? Let's sya there's quick way to match
>> whether the page is part of the remapped large page, what can pageattr
>> do differently then? Applying the same attribute to both mappings?
>> Failing or filtering set_memory_*()?
>
> It would have to split the page. Perhaps there wouldn't be a need to
> apply the new attribute to the page(s) that is(are) in the process
> of getting its(their) attribute(s) changed; instead, just don't
> re-establish a 4k mapping for those pages that aren't part of the
> per-CPU space.
Ah... right. Splitting the remapped area should do the trick, so now
the question is whether it would worth all the trouble or should we
just forget about remapping and use 4k on NUMA machines. I don't have
much clue here. Andi seems to think there's no reason to bother with
PMD mappings. Ingo, what do you think?
Thanks.
--
tejun
--
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