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 AEB46C433EF for ; Sun, 15 May 2022 09:02:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0E176B0073; Sun, 15 May 2022 05:02:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CBE1B6B0075; Sun, 15 May 2022 05:02:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B85CE6B0078; Sun, 15 May 2022 05:02:18 -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 A5A3C6B0073 for ; Sun, 15 May 2022 05:02:18 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 66304E5C for ; Sun, 15 May 2022 09:02:18 +0000 (UTC) X-FDA: 79467385956.08.A93852E Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf22.hostedemail.com (Postfix) with ESMTP id CED9FC00C8 for ; Sun, 15 May 2022 09:02:15 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652605335; 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=2mDUSPGcPZzaMW7gML3LPCubye4TyOLT8f3zTeFZihs=; b=a22bC37E63DPGgcF/cz1PLTXMxwvqwE5Kp+PQ0VF0jHQ0m9peE6Ue6mUsIqGSFnIv2qQwL nTN8sn/6BFGBP6WlL2ErTQYt+ZwrJYk7ccXnKdwRmmHOnG5bBJSCJYlFUqDZdDYV1oDVgS qkHyXRyBc1958ETMJ7qJdemW9yvK38LhcpYIv0KJXe2JyYNGZFF41b3cexDMBrvcnvCZrT +RhA7KFtNXGvpTrg9UnA715yqzW8lL+ak/moaxwSnJxvt4s+BUpIVOdbKPU0pr4CJubhas HywYq5cSza59BEFAsRU7a5Z0Uq63NhqIHROLx6zgBBGYQ+v51Yw8DVF2wY8ULA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652605335; 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=2mDUSPGcPZzaMW7gML3LPCubye4TyOLT8f3zTeFZihs=; b=l0ei/dXdudkTpXgkRl5uoJzI+bBhcdRFKRkbbHQSjBtbrfr0fS5DeQhr6NQUU/DiIWjZu3 JDO8C2GHyWd5TpAQ== To: "Edgecombe, Rick P" , "kirill.shutemov@linux.intel.com" Cc: "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" , "aryabinin@virtuozzo.com" , "dvyukov@google.com" , "x86@kernel.org" , "ak@linux.intel.com" , "Lutomirski, Andy" , "glider@google.com" Subject: Re: [RFCv2 03/10] x86: Introduce userspace API to handle per-thread features In-Reply-To: <9e59305039f2c8077ee087313d1df5ff06028cfe.camel@intel.com> References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511022751.65540-5-kirill.shutemov@linux.intel.com> <20220513230958.dbxp6m3y3lnq74qb@black.fi.intel.com> <543eb3ff98f624c6cfa1d450ac3e9ae8934c7c38.camel@intel.com> <87k0aose62.ffs@tglx> <9e59305039f2c8077ee087313d1df5ff06028cfe.camel@intel.com> Date: Sun, 15 May 2022 11:02:15 +0200 Message-ID: <87zgjjqico.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: yqyb6srud4bfof18tsbwwnd1epen3ex5 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CED9FC00C8 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=a22bC37E; dkim=pass header.d=linutronix.de header.s=2020e header.b="l0ei/dXd"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf22.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-HE-Tag: 1652605335-255648 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 Sat, May 14 2022 at 23:06, Edgecombe, Rick P wrote: > On Sat, 2022-05-14 at 10:37 +0200, Thomas Gleixner wrote: >> > "On success, arch_prctl() returns positive values; on error, -1 is >> > returned, and errno is set to indicate the error." >> >> Why? >> >> prctl(GET, &out) >> >> is the pattern used all over the place. > > It seems better to me, but we also need to pass something in. > > The idea of the "enable" operation is that userspace would pass in all > the features that it wants in one call, and then find out back what was > successfully enabled. So unlike the other arch_prctl()s, it wants to > pass something in AND get a result in one arch_prctl() call. It doesn't > need to check what is supported ahead of time. Since these enabling > operations can fail (OOM, etc), userspace has to handle unexpected per- > feature failure anyway. So it just blindly asks for what it wants. I'm not convinced at all, that this wholesale enabling of independent features makes any sense. That would require: - that all features are strict binary of/off which is alredy not the case with LAM due to the different mask sizes. - that user space knows at some potentially early point of process startup which features it needs. Some of them might be requested later when libraries are loaded, but that would be too late for others. Aside of that, if you lump all these things together, what's the semantics of this feature lump in case of failure: Try to enable the rest when one fails, skip the rest, roll back? Also such a feature lump results in a demultiplexing prctl() which is code wise always inferior to dedicated controls. > Any objections to having it write back the result in the same > structure? Why not. > Otherwise, the option that used to be used here was a "status" > arch_prctl(), which was called separately to find out what actually got > enabled after an "enable" call. That fit with the GET/SET semantics > already in place. > > I guess we could also get rid of the batch enabling idea, and just have > one "enable" call per feature too. But then it is syscall heavy. This is not a runtime hotpath problem. Those prctls() happen once when the process starts, so having three which are designed for the individual purpose instead of one ill defined is definitely the better choice. Premature optimization is never a good idea. Keep it simple is the right starting point. If it really turns out to be something which matters, then you can provide a batch interface later on if it makes sense to do so, but see above. Thanks, tglx