From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 596062BEC5E for ; Sun, 7 Dec 2025 10:37:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765103881; cv=none; b=PWhIgLWQ7fqRklDK9tB6MPVrka2couecQOwkSu44g+cHlNFMY26UHnQzBj+FiiQt/B2Cdpf2y6gRol+lvwP2VDZx8tcKahZjx2GfWyBRjcMJvVM0BFdP7h3qwySh3h5GMVB0R/XjaMrhOkQ/W20QvH1UFQCsTNRBl/7nPpKUJJg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765103881; c=relaxed/simple; bh=QsamyEM5RiLzdFKH85jlO/UhpGeL8FEIU+mMd/9PxiI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NyTkamJSJJp1CV04mNAGZ2t3vFPcy1pwecfqCahKIwAEMBvsUhgP6uMI5SPqGwswvdf6JGxU3A1xOqBsawiEr1CUi5aGhlnAL6thx2DrSr78KkQLaA/eL354SEUpjFLn8G6m414aYloXH3Jc9IxAhqDt3w0vw1X2tMLb0tXAtlE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hejKp3ZL; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hejKp3ZL" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4779a637712so26357755e9.1 for ; Sun, 07 Dec 2025 02:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765103878; x=1765708678; darn=vger.kernel.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=yiFmqmVM8Tzc3/pX6LppdlSzcPKAUCpuWPYMDLim8AI=; b=hejKp3ZLF+pvmas6VQp3Pbiq8tXgGG/g9CYjDU6nd0z1KNrnJdrZ15bdZUYYOhZthz IE84RnPPiYj80jyiIrWIpxyqKC4Lzt6d6jwT8mtw+ZosLNrW2Jv6g1LqAb8ZYwQnQWvU LqGP59mfE0EvepbbKmcYfRAbE3UZ9FbBtrmXlYnyde8SHAJ9dsI/snRG78r+uaWGFBGs 9GeUQkR7N7E8hDJMtyPfkN0gd6CCCKR9lII+EHTqX/rYKYPs7Dvc15F1yegETBpJ1uQV W1YhRvr1DyNmHCrN6BwIG7B1MyhDIj7fUqCcscx+v3CHwKtZGZrcEesVlXXAbG0GNAR9 LUkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765103878; x=1765708678; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yiFmqmVM8Tzc3/pX6LppdlSzcPKAUCpuWPYMDLim8AI=; b=No48Rc3RgkaPK7zBVLxVdlnDv/dj5xBib97vD80u6Ki12VNLVlBs98Yd6kB6c0S81H 2xGkEwiboBZ0iBIKq/y9674kqDPyLytme4qLMyOxkXAAbTDUkI0B1yLgxVSrvsyBxBmu jryN0pE4tiRjsDiwWxAoJGI4zUgKlznMspHPddFnUKYs06xTp9CCSuem4zJpyVh3UadI Kw1JhVXv+mZWFVThiHjATO01Cv9SqHRvEr3mmzKgynp9QGSN+gePHcmWucJoKe3MwIYA 34GyELY0DV9zLbqAFMKY/qOiKDfXOyVvBxBpyq96rbGMzRcOURj+bMrry29wKE25Os/n CEQQ== X-Forwarded-Encrypted: i=1; AJvYcCVnzIqawil30yM5Tfg1ZK/fPVAbJ+8C03jG9m1mb1k6GKIXaTlA4f6848oU/wFR7fZkjBpH6HogNMfND7Q=@vger.kernel.org X-Gm-Message-State: AOJu0YyFG0DTsZIEKWHnEgoGj9KtfAFZBFgKE0xDrLsfzhSAemUh1Adr ItosDWs4RKq0Rlr3yKvSY1adlI2+yrUP7RtWejPDknCqzt5ozzcQpOAj X-Gm-Gg: ASbGnctxuH5/i/FfHlYG0ZFLasHl9xODcdOx5FlOdpXq9rz7dhc3iio67u3ZiWvBEP2 RSfVL6sL2g0HyH7Hl2p4i8ZO0YtLnQq6sbyVo6UmAedHZIAz52H0f8buKuR1ECuVDU8xoR/NxmS ZTN9Kizee4H2ZrSSKAwtuA/Qm9kQ2mpvcq6OWKkGax/CXPLMAqcDfPY9QfLqU+hFoHF3DYaJTII nJZhLvNsoUFRvhgwY56pbjNe7MotMwT731Dnn7wN4wIt14BAlhLoNqCI8IqXEwyBpDsaX6EHPRc cE1SKQblBrA58g2hdsKrbFxE9dlCCUCojBwftc4pkwflVTC66kWtJjLep1m4KVsjdNkMGSMSfzq yvhJu9jvWMk4fNC2s+TyjBOdyEzolpph9A1cfA6XSOshZZkyCgwJDiOf0GxgpaDXomxnII2QNN6 hj7GjIAS+sdAATVqWB8vWVBDJAFNHPvsivDYxzRLnZjMzUDvQO939b X-Google-Smtp-Source: AGHT+IFHsj32Bs/JaOUHvHxvy9WXs85BjT7KVW4hKHqqWBOsdWdXQQobTbt0UPYwtiptAXg+ckH2Sw== X-Received: by 2002:a05:600c:d2:b0:479:3a86:dc1e with SMTP id 5b1f17b1804b1-4793a86dcc6mr28759625e9.36.1765103877360; Sun, 07 Dec 2025 02:37:57 -0800 (PST) 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-4792b04e03bsm99035395e9.7.2025.12.07.02.37.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Dec 2025 02:37:57 -0800 (PST) Date: Sun, 7 Dec 2025 10:37:55 +0000 From: David Laight To: Mateusz Guzik Cc: Matthew Wilcox , oleg@redhat.com, brauner@kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH v3 2/2] pid: only take pidmap_lock once on alloc Message-ID: <20251207103755.70be2f89@pumpkin> In-Reply-To: References: <20251206131955.780557-1-mjguzik@gmail.com> <20251206131955.780557-3-mjguzik@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 7 Dec 2025 10:21:35 +0100 Mateusz Guzik wrote: > On Sun, Dec 7, 2025 at 8:21=E2=80=AFAM Matthew Wilcox wrote: > > > > On Sat, Dec 06, 2025 at 02:19:55PM +0100, Mateusz Guzik wrote: =20 > > > - if (!pid) > > > + if (unlikely(!pid)) =20 > > > > Does this change anything? I was under the impression that gcc already > > treats !p as unlikely. =20 >=20 > I don't know if gcc is guaranteed to act like that, most of my > experience is with clang which was rather inconsistent about it. >=20 If nothing else unlikely() are information for the human (and other) reader. In my experience, a simple if () is always coded as a forwards jump around the controlled code - regardless of any likely/unlikely annotation. Similarly 'if () continue/break' is an immediate jump to the loop end code. You need to add a non-empty 'else' branch, or something before the continue/break for the un/likely to have an effect (an asm() comment will d= o). While some instruction sets have explicit 'branch expected taken' markers others (like x86 - except P6) don't. Similarly some cpu predict backwards branches taken if their is nothing in the branch predictor, others (including some x86) just use the relevant branch predictor 'slot' without regard for the actual branch address. Then there is the branch prediction done by the instruction fetch/decode unit, that has a tendency to use markers on the cache line - so doesn't necessarily even check it is a branch instruction! Basically the coder doesn't have much control at all on many cpu. Oh, and using un/likely() can make the code worse. David =20