Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933061AbcLIK1L (ORCPT ); Fri, 9 Dec 2016 05:27:11 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:53474 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932960AbcLIK1H (ORCPT ); Fri, 9 Dec 2016 05:27:07 -0500 From: Arnd Bergmann To: Ingo Molnar Cc: "Kirill A. Shutemov" , Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Dave Hansen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , maxim.kuvyrkov@linaro.org, Catalin Marinas , Will Deacon , broonie@kernel.org, schwidefsky@de.ibm.com Subject: Re: [RFC, PATCHv1 00/28] 5-level paging Date: Fri, 09 Dec 2016 11:24:12 +0100 Message-ID: <13962749.Q2mLWEctkQ@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161209050130.GC2595@gmail.com> References: <20161208162150.148763-1-kirill.shutemov@linux.intel.com> <20161209050130.GC2595@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Zt4BIn0HUmEgrTLKvnbmCjjFgGk7Hp2CZDKZoaZvNo7aNJTiHCd nrUXSRi+a9WwxsAbiC3Gha/3avuTnjUlk9L8NCAPndpfuPL9ExV4eGveI1rwGrkP3IYVEra g2ghZh/gF6JcClSKpLYtxJWnYDODNw6cap/Ks2Wse0cqoiSjjCWNDEsJ51G7TJEMhu+VLSr UKZHP5sSp+Nj4HmK26nvA== X-UI-Out-Filterresults: notjunk:1;V01:K0:vMIObl1+css=:XxQGp2oedrn67ofjoetEpE 2teRt/BUhz4sfDeHvQZYXS6D5IPRQ9pnd22wkJ+T9V6cX5YzNplITHAeBfQ/yWKD/+DmXTczs BzO8HRpxFXEaHwRK+ZSAjCV6eTC8rlbShtHj+S1amo4FTBBBiTI7j1r0lpGJyCfI/wN8RT7mj WGZ7TrYKVFHDpHT0ZMYYFhZ5FFSagQ83gUEq7hOqyWcJtJsPNbyy3OW74mwoZmgc1oEzlipc+ 73cVQPS/2po56TwAvAw17vXjmSnbkCAp1OVdm6Q60EPgNYpSHF0x4VtkBIvJeV+TFQyDjfmF3 cIFC4rYIPAJ/TIhgkctj8oeCniJO+lrCXn7wdHIVyDkfPAmG4FaNu4kykkjy4SJVqdw5+SGBp eUrMg30ImSSxFiOCb2xjVSoWA4Fe8qq+575Xq/Jdsh3WxWcKTK+80H1xfogWcXeM4dfX/9m+t ojkIB3ueqM+hv1DkZPOsvvjx+xN2hO/VBMCY/ZR28XMA8IAE9PiYq8NkIzWIFl7j6Qh6Qacmj fSOkxg7NNXp6jXhA9HmBUfJ2qnq5ckVRIPqRYP6yJkhrJ9HvA/rQjqywxcxg5qb0d5H7MTMvi JwG8cGDRr3OTWFxMumf8Vhimol08ZApzJK1wPLdvRq0NKHpL/X7873pn4n0hntOSc7ZvmVXVA Qw8e0Ae0XteJ6mQKTxlKL6fSyh+WxJ8bz8hEF0K+iK9tKh9+HYb72oL8tXOCvugDs5oeHDaPH E+qTo3E5R5uluq8t Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1647 Lines: 36 On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote: > > - Handle opt-in wider address space for userspace. > > > > Not all userspace is ready to handle addresses wider than current > > 47-bits. At least some JIT compiler make use of upper bits to encode > > their info. > > > > We need to have an interface to opt-in wider addresses from userspace > > to avoid regressions. > > > > For now, I've included testing-only patch which bumps TASK_SIZE to > > 56-bits. This can be handy for testing to see what breaks if we max-out > > size of virtual address space. > > So this is just a detail - but it sounds a bit limiting to me to provide an 'opt > in' flag for something that will work just fine on the vast majority of 64-bit > software. > > Please make this an opt out compatibility flag instead: similar to how we handle > address space layout limitations/quirks ABI details, such as ADDR_LIMIT_32BIT, > ADDR_LIMIT_3GB, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc. We've had a similar discussion about JIT software on ARM64, which has a wide range of supported page table layouts and some software wants to limit that to a specific number. I don't remember the outcome of that discussion, but I'm adding a few people to Cc that might remember. There have also been some discussions in the past to make the depth of the page table a per-task decision on s390, since you may have some tasks that run just fine with two or three levels of paging while another task actually wants the full 64-bit address space. I wonder how much extra work this would be on top of the boot-time option. Arnd