From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68E8FC433F5 for ; Fri, 13 May 2022 00:46:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3FA86B0075; Thu, 12 May 2022 20:46:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC7BC8D0002; Thu, 12 May 2022 20:46:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B413E8D0001; Thu, 12 May 2022 20:46:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9E31F6B0075 for ; Thu, 12 May 2022 20:46:32 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7DC4220AA9 for ; Fri, 13 May 2022 00:46:32 +0000 (UTC) X-FDA: 79458879024.14.3F62D65 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf09.hostedemail.com (Postfix) with ESMTP id 6812614009B for ; Fri, 13 May 2022 00:46:23 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652402789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xd8me3zJySDc9HaBBmJv3HcDQGa35Kv/TIv1nYHhe6s=; b=vddEIncvnG/nsi6VTvMIXkJG01KEpPIw3AwzEeuxtq8S6ZYkEPjYwvcjt4O3sV8QdzrITN mLP6Yh9yPHI8BmaCCS3CKeGxSslKlxZ5Q1J4+mqMz8FFAVf//4OfBRQMEb0m38qxwX1A7w fmHEfDokYTHRdP5GxH3UMMLCOt36M3x7Va+TaPazXgrn9o2ksmG7Sm4sgcF6b8fsffAhGN 1WLwZMooyXlLFKdMxEHGA7tZTXuUOqBZNEPFEeHwID82pe3AAzREkXePwOtYr9Oi3ZCCdO Pxw6dEPuKAl4yt4nJOWyTz76y6D62MF7wURBFgOS8QAQBCx826uZolpV6BhMEQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652402789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xd8me3zJySDc9HaBBmJv3HcDQGa35Kv/TIv1nYHhe6s=; b=3F06efiAuRLVvpsUQlMIvmVqjkkqV4jjSnt5hSCvdcckZpqqCC3UcmlC+Sjf38puwTU16t VMWqX7G1P0OqADBw== To: "H.J. Lu" Cc: Dave Hansen , Peter Zijlstra , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , the arch/x86 maintainers , Alexander Potapenko , Dmitry Vyukov , Andi Kleen , Rick Edgecombe , Linux-MM , LKML Subject: Re: [RFCv2 00/10] Linear Address Masking enabling In-Reply-To: References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> <875ymav8ul.ffs@tglx> <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> <87o802tjd7.ffs@tglx> Date: Fri, 13 May 2022 02:46:28 +0200 Message-ID: <87czgitg2j.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6812614009B X-Stat-Signature: j9iw6pnp79z1hm5fn64htbyw4x3sphs4 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=vddEIncv; dkim=pass header.d=linutronix.de header.s=2020e header.b=3F06efiA; spf=pass (imf09.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1652402783-802795 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 12 2022 at 17:08, H. J. Lu wrote: > On Thu, May 12, 2022 at 4:35 PM Thomas Gleixner wrote: >> > When an application asks for LAM_U57, I expect it will store tags in >> > upper 6 bits, even if the kernel enables LAM_U48. >> >> The kernel does not enable LAM_U48 when the application only wants to >> have LAM_U57, because that would restrict the address space of the >> application to 47 bits on 5-level capable system for no reason. >> >> So what are you trying to tell me? >> > I am expecting applications to ask for LAM_U48 or LAM_U57, not just > LAM. That still does not tell anything. You can as well tell me, that this will depend on the moon phase. That would be more telling at least. If we commit to an ABI, which we have to support forever, then we want factual arguments, not expectations. The fact that hardware supports 5 variants does not mean that all of them make sense to support in the OS. Quite the contrary, 99% of all 'flexible' hardware features are based on bogus assumptions. The worst of these assumptions is: 'We can handle this in software' Sure, most of the trainwrecks hardware people provide can be 'handled' in software, but you have to consider the price for doing so. The price is that we amount technical debt. You are well aware of this as you have contributed your share of technical debt by cramming unsupportable crap into user space projects prematurely. So can you please take a step back and seriously think about the semantics and long term consequences instead of providing handwaving expectations which are biased by uninformed wishful thinking, AKA marketing? Thanks, tglx