linux-kernel - Re: remap allocator for per-CPU memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A0ACB29.5030009@novell.com>
Date:	Wed, 13 May 2009 22:29:13 +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 Beulich wrote:
> I think the only two alternatives are
> 
> (a) don't use large pages in the first place here, or

Seems like the first candidate at the moment.

> (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_*()?

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/