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 5781BC77B7C for ; Tue, 24 Jun 2025 21:08:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ADD376B00AD; Tue, 24 Jun 2025 17:08:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB4816B00AE; Tue, 24 Jun 2025 17:08:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A3756B00AF; Tue, 24 Jun 2025 17:08:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 866446B00AD for ; Tue, 24 Jun 2025 17:08:23 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0485C1A10D7 for ; Tue, 24 Jun 2025 21:08:22 +0000 (UTC) X-FDA: 83591532486.12.537590E Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf08.hostedemail.com (Postfix) with ESMTP id EE0D4160008 for ; Tue, 24 Jun 2025 21:08:20 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EbaO9yE1; spf=pass (imf08.hostedemail.com: domain of david.laight.linux@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=david.laight.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750799301; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=itvx7IDSqd1Qu+kDl1q7+IKMKfpB6umE1igfQExJBWU=; b=4nnT82w7xSOCe64bQyK+HIeF+eBoeU9K5V6ePfmjIXCbSDmWe4wkwGkHhz0z/xSOOUPgcf OoXvqx0u1S2+xmaqL1JAaULfJOPDRgqgnCQIpO+YZD/SNIOnbUThBWSvfwT9lGIdhA5Gy1 z7417n5JE8uoG1YsRA491DvIjf1FMKo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750799301; a=rsa-sha256; cv=none; b=6m4EQjUtkJq3YoiDAdvnjc4eW+Sm1SRLHUP/KKtUigVmlX3NDxy0ve9DpJkCD+c/3Zojot 3h+4+XKaQOmS2WZ1KQ+XLUZmZWmlxZ/KOyMIYM45/laok68azGkTeqPvzZhTzp7vDc+Z3h W5OEwaAtEEKObqdQIrrDgrHeq5l5c6o= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EbaO9yE1; spf=pass (imf08.hostedemail.com: domain of david.laight.linux@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=david.laight.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-3a53359dea5so2864421f8f.0 for ; Tue, 24 Jun 2025 14:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750799299; x=1751404099; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=itvx7IDSqd1Qu+kDl1q7+IKMKfpB6umE1igfQExJBWU=; b=EbaO9yE1+ICtf/VorjKRwC3UOQucTo/Hfr/NLkg+2zVTZyltjGIw8eBaY9t2cBKI29 fuT2j6sekG2qGmT87+cg76nLzvnpyNur6ghGmCkpnu4t+Gk3/cjBAEWsEhdWKpHWsFdm xHbahrIb7YR+EoolC7555JTJNkkoqFodDF47BfhR42WG5TdMLP0aIJQswV87O+//3Gyw QO6a8809s8oSV7/Bh5xZXKrrJsgdJ6UP7xYV6bpEME29MckS2WtOrHJWq46GrBMdTh9t pX7IEZ1o9703MIQ2LfFqFwwou1IgBjEiHz+Xg6GQJC7ZoPnNfZElPQtGtlR4KQtOKUXn VSWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750799299; x=1751404099; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=itvx7IDSqd1Qu+kDl1q7+IKMKfpB6umE1igfQExJBWU=; b=ZTP9YrbUHka6tWeYYhRi4jp7x4q1yAGfmYZqJkFcJ5UDzvFseYdobXF0ixMXk2AGBZ fEDj7yY685ABol11ab0BVE/ib9U6HxH1i8wEP7E3aFpy11PxS2jkljm3ay9JW+vNUBCo Jye1uqXaj0UvZFZqMj8t/KortEn15BauTXKfzaWAGEgpkxmXbv7Ou33dpOT8lGmbB5z3 nKCVqUA/NvTwoftF+qIrG4tCBo0TW+ibw0gUXkjMmMKWg/q53ngbPYvAvq6Hx4Yl2sZD PJJMQkAHltyTdEGXBIMW9cz8JHzuS0OBPlg3WGxY/IOxPbvGSgyZCMfaEroSbbZmeRoz FGqQ== X-Forwarded-Encrypted: i=1; AJvYcCU+zKfF6IciGBKDhFKTXNLlbcdWQf8w89FMqlQZHYEuqZ30nBkT8JI2U1sgrnG5kfR4iQM7sTVd5g==@kvack.org X-Gm-Message-State: AOJu0Yw+OnC3umHxAwNVyzK2Hd4fomTpL2GeHBXIfdwI3o6dmwXtDAr5 TFSXyV+VcC6NnqYdXG/k1B21EE8T2QixEixg7UmPOOYvc3jAX8DkGY29 X-Gm-Gg: ASbGncujEtodD4HoGGHhfFVCOwsjUZJecCS5ScGXFKXqMebTnaqIUVLzNxdWj/ldWqL I60yYm+bbco92YgACBoEh1Ehfm8jg1jf2Fzt3TYOEu6RANP5k/7J0kx1St+mnmVsK+AjNeJqB1U oT1cW9DcrOEuD5Mr7CzjhBDQ1p6hz7gypyRpj6uWY+y3ZdkE4UC0kkUWjPLn2UdCnDosCxCwjLC iUWMCp4MQgi5BnCfkZkXWb2kWNKfxpFYDNeZuT7uubrwpUsW/uC9y6NyKykopbQQ7vs1SyNQ6BP UTSYkQVjACWIGAfYXDt+mMtZyGNBln3sepMN6LNNsfgfucGA8E9pE4YIxCJD6tHpQzqo5n2sg84 RawnUMzokLpTxNpUC3c3lIZS8 X-Google-Smtp-Source: AGHT+IGwHH+3Fto7qgv3C8c/BdcTcAmM+Clmw2M+ojfy6KRjk/KACDvzw9BkPqhVjXarh8ndrQu0nQ== X-Received: by 2002:a05:6000:2407:b0:3a4:ec23:dba7 with SMTP id ffacd0b85a97d-3a6ed66a42amr135573f8f.31.1750799299081; Tue, 24 Jun 2025 14:08:19 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-453823ad186sm165755e9.21.2025.06.24.14.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jun 2025 14:08:18 -0700 (PDT) Date: Tue, 24 Jun 2025 22:08:16 +0100 From: David Laight To: Segher Boessenkool Cc: Christophe Leroy , Michael Ellerman , Nicholas Piggin , Naveen N Rao , Madhavan Srinivasan , Alexander Viro , Christian Brauner , Jan Kara , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , Davidlohr Bueso , Andre Almeida , Andrew Morton , Dave Hansen , Linus Torvalds , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/5] powerpc: Implement masked user access Message-ID: <20250624220816.078f960d@pumpkin> In-Reply-To: <20250624182505.GH17294@gate.crashing.org> References: <20250622172043.3fb0e54c@pumpkin> <20250624131714.GG17294@gate.crashing.org> <20250624175001.148a768f@pumpkin> <20250624182505.GH17294@gate.crashing.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EE0D4160008 X-Stat-Signature: jb8zht6uc6mdrndcatfgrd5zi7so9tcb X-Rspam-User: X-HE-Tag: 1750799300-495788 X-HE-Meta: U2FsdGVkX1/g8D0hCB+TLtCL21hwTy3MLPsTLWkFajepM2RG6uCkLme5KYi4QvSocg9jVLi3hHdymIwealnRskV1FXySECHRdwaurFenFc0Dchfg51WHy2g2p5uMTtFxtke8DG/r8STIMRMkLmGORBNjydJZ2BkPRyMJSub9vfLvMd6th6ToM5t1WLJP4JZMNjzznCNPI6MbHInO/FCbslJOG2DFJbHelgKiUqUKvQ5qV7glrEoot62Ealk0EgfnNKdUbh+4WuVEJLRryGGIqq/xec4Pj5H2FD+3WIxK2ZHK4aisytBlRYBvnI0VCFKEDuvwdrswTzXN0ZXrAQm7WOq8XhbBlQd+BxX5lQKDznke/o5svfDzRyZfyBNkPhLVcr0al9CQzjsqVjNKdJ3K3cE5fHLOS4PyYiWY9R2J60YTVnRAWAroVuuaUXlQOIDQTo0Aqrw+iM73wdlifDPNz2rQqa9Bbyzz8/WLtaq0uWjPbHzISPP2iSMr7AJaW1Jm+aBmdgxP7DvGp+nqKcFh0+HgWl5efvGWkXHdK5H0vChjXjhlcOSbCvfl+6u3GJ5IlewG0SzrQ+nj1/9DHowT68TCrWq3VrqLj4VyHGiHPMgYtbzFfbcL5+LBJ4uinmwxmFYL4uZRA7uP8dv1Sl8c1DjMRQSeh16trv15X+eTzILnmkN/gme04+aLnxbfEAvyc/u/9OGcH5yFgMr3jLQPp4O2qFVp6JLZKrq6Dbf7b0FYyal47qfGEk5nZ22weFEAswQhdB/zk4rP9a22fb4gR7FMfo9YRTf54Lze1rXUyVkAA4vcEXKy37cuRzc9nqMOeSFLZkMdSSp17KqF61XsTGY8JKegvEdCGtmQfSiuyUD/yAJrTOnnxIQIJMzFgWKTwGmtD7V1gPbfREWhmE2F0VnB9SjeMAJXM4IfuuS5SwItMVmOMkVIWtscktNiAawwpfOHiK1WhW9cJNQ8W6S J77tq0CG p0lQaz/EEVLt85hkt0ZSdFWTqt+zxHcYYyqq//gehZDSgHYRDYE3FFdydnrxYV1IwPsqEjXlp7rHAVST8eyQviP4FmwvedBLalnGLjTYFQNlW35uupEdOdH+ZAP3t6MMcDkJRds8/5KPF5xVmRtAGQMMW8/b4I3QTtBhrsKdUTHkVVvt+0qA+/27xft6QHUWBg1Ge1PW7e8x6cWyNa+prrZiA6FKMXYoLfhWLNhaS2oldHluS9q4V/8ep7NLvq1okQDuw0l7Q3GUIRTXpUzUsTD9LJ+hyRlYY5Yoj0tHnb9kgUwcxfjUptCSQA75au2BijCjbejF6DZAvlZq4eDJ/8wJH5O2CWeiNn0z+tu+zstQpbZCXBKj0sPJhd5WSfxhSbxKnpmyp+y5ePBFLWnQh9UKT1PSBD7LWCNdDeC12RvegYaraXVTW4biMMj0ralPc6FO6azpJnWeq2Rw= 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: List-Subscribe: List-Unsubscribe: On Tue, 24 Jun 2025 13:25:05 -0500 Segher Boessenkool wrote: > Hi! > > On Tue, Jun 24, 2025 at 05:50:01PM +0100, David Laight wrote: > > On Tue, 24 Jun 2025 08:17:14 -0500 > > Segher Boessenkool wrote: > > > > > On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote: > > > > Ah ok, I overlooked that, I didn't know the cmove instruction, seem > > > > similar to the isel instruction on powerpc e500. > > > > > > cmove does a move (register or memory) when some condition is true. > > > > The destination of x86 'cmov' is always a register (only the source can be > > memory - and is probably always read). > > Both source operands can be mem, right? But probably not both at the > same time. It only has one 'real' source, but the implementation could easily read the destination register and then decide which value to write back - rather than doing a conditional write to the register file. A conditional write would be a right PITA for the alu result forwarding logic > > > It is a also a computational instruction. > > Terminology... > > x86 is not a RISC architecture, or more generally, a load/store > architecture. It sort of is these days. The memory transfers are separate u-ops, so a 'reg += mem' instruction is split into two be the decoder. Although some u-ops get merged together and executed in one clock, obvious example is some 'compare+branch' pairs. > A computational instruction is one that doesn't touch memory or does a > branch, or some system function, some supervisor or hypervisor > instruction maybe. > > x86 does not have many computational insns, most insns can touch > memory :-) Except that the memory 'bit' is executed separately from any alu 'stuff'. So for a 'reg += mem' instruction the memory read can be started as soon as the registers that contain the address are valid, the 'add' requires the memory read have completed and the instruction that generated the old value of 'reg' have completed - which could be waiting on all sorts of things (like a divide). Once both values are ready the 'add' can be executed (provided a suitable alu is available). > (The important thing is that most computational insns do not ever cause > exceptions, the only exceptions are if you divide by zero or > similar :-) ) > > > It may well always do the register write - hard to detect. > > > > There is a planned new instruction that would do a conditional write > > to memory - but not on any cpu yet. > > Interesting! Instructions like the atomic store insns we got for p9, > maybe? They can do minimum/maximum and various kinds of more generic > reductions and similar. I think they are only conditional stores. But they do save a conditional branch. A late disable of a memory write is far less problematic than a disabled register file write. No one minds (too much) about slight delays between writes and reads of the same location (reduced by a store to load forwarder) but you don't want to lose clocks between adjacent simple alu instructions. For my sins I re-implemented a soft cpu last year... Which doesn't have a 'cmov' :-( > > > > isel (which is base PowerPC, not something "e500" only) is a > > > computational instruction, it copies one of two registers to a third, > > > which of the two is decided by any bit in the condition register. > > > > Does that mean it could be used for all the ppc cpu variants? > > No, only things that implement architecture version of 2.03 or later. > That is from 2006, so essentially everything that is still made > implements it :-) > > But ancient things do not. Both 970 (Apple G5) and Cell BE do not yet > have it (they are ISA 2.01 and 2.02 respectively). And the older p5's > do not have it yet either, but the newer ones do. > > And all classic PowerPC is ISA 1.xx of course. Medieval CPUs :-) That make more sense than the list in patch 5/5. > > > > But sure, seen from very far off both isel and cmove can be used to > > > implement the ternary operator ("?:"), are similar in that way :-) > > > > Which is exactly what you want to avoid speculation. > > There are cheaper / simpler / more effective / better ways to get that, > but sure, everything is better than a conditional branch, always :-) Everything except a TLB miss :-) And for access_ok() avoiding the conditional is a good enough reason to use a 'conditional move' instruction. Avoiding speculation is actually free. > > > Segher