From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 30/30] x32: Add x32 VDSO support Date: Tue, 21 Feb 2012 11:56:49 -0800 Message-ID: <4F43F701.80205@zytor.com> References: <1329696488-16970-1-git-send-email-hpa@zytor.com> <1329696488-16970-31-git-send-email-hpa@zytor.com> <4F42E171.9080005@mit.edu> <4F431665.3010004@zytor.com> <4F43D98D.1020406@zytor.com> <4F43EA83.6020203@zytor.com> <4F43F25E.3030004@zytor.com> <4F43F54D.50201@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andrew Lutomirski Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, akpm@linux-foundation.org, hjl.tools@gmail.com List-Id: linux-arch.vger.kernel.org On 02/21/2012 11:51 AM, Andrew Lutomirski wrote: >> >> No, that wouldn't help. The situation is actually quite similar to the >> current situation where we have an unshared fourth level, but since the >> fourth entries are 512G per entry, we would have to push unsharing of >> the kernel address space at least one more level (1G), possibly two >> (2M). Painful. >> >> The main advantage of a separate cr3 would be that we wouldn't need the >> unshared top level for the kernel side. > > Also, as is, if the top level wants to be per-cpu *and* per-task, > that's a big explosion of page tables that all need to stay in sync. > Fair enough. -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:45198 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754295Ab2BUT5F (ORCPT ); Tue, 21 Feb 2012 14:57:05 -0500 Message-ID: <4F43F701.80205@zytor.com> Date: Tue, 21 Feb 2012 11:56:49 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH 30/30] x32: Add x32 VDSO support References: <1329696488-16970-1-git-send-email-hpa@zytor.com> <1329696488-16970-31-git-send-email-hpa@zytor.com> <4F42E171.9080005@mit.edu> <4F431665.3010004@zytor.com> <4F43D98D.1020406@zytor.com> <4F43EA83.6020203@zytor.com> <4F43F25E.3030004@zytor.com> <4F43F54D.50201@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andrew Lutomirski Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, akpm@linux-foundation.org, hjl.tools@gmail.com Message-ID: <20120221195649.NK5uEMgTVqRfFH1ktAgQqRAKA4wt1LGmXNuJJiDQqD4@z> On 02/21/2012 11:51 AM, Andrew Lutomirski wrote: >> >> No, that wouldn't help. The situation is actually quite similar to the >> current situation where we have an unshared fourth level, but since the >> fourth entries are 512G per entry, we would have to push unsharing of >> the kernel address space at least one more level (1G), possibly two >> (2M). Painful. >> >> The main advantage of a separate cr3 would be that we wouldn't need the >> unshared top level for the kernel side. > > Also, as is, if the top level wants to be per-cpu *and* per-task, > that's a big explosion of page tables that all need to stay in sync. > Fair enough. -hpa