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 814EAC3600B for ; Wed, 26 Mar 2025 23:57:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D03772800BA; Wed, 26 Mar 2025 19:57:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB3162800A5; Wed, 26 Mar 2025 19:57:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7B432800BA; Wed, 26 Mar 2025 19:57:33 -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 94E5A2800A5 for ; Wed, 26 Mar 2025 19:57:33 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 156A812044F for ; Wed, 26 Mar 2025 23:57:35 +0000 (UTC) X-FDA: 83265366870.12.090558B Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf20.hostedemail.com (Postfix) with ESMTP id 29B621C000B for ; Wed, 26 Mar 2025 23:57:32 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FvcnxkTv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743033453; 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=tfL0zZBVe1RxEvNcNmE6dfxCA/2Hz+Ouu0xAFqUlH9A=; b=mFioWct/AE1DtdSvBAFvr99AOAbTbv3qKubqF+T+ZDV6YbZdGLxtwNqnPGvo/ppsKTmjt4 8SCbWRojRTdT/AEEjcO8L7//1YBbcltxrQJl+ob93Aoonb8eGP7a3jJx1q4TQo7By7wC4O cHwqB2a0/+XgT3FW8p+0PlJnzpGwsA4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=FvcnxkTv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743033453; a=rsa-sha256; cv=none; b=4zAaoYgBZez7mOj4pX2oq+dZIww5PS0idSHmnNxvRy75P5qNI01dufWnSuYD6atSrAdTUX k99SRDEB0RfiCutggPwH2o+/drJnMkeKzwV0v85JjB7nLwfeY6LYV+PeTd+PmOPygK6Awj Br4TebTODlCSmbwGElLsVl0KgJEz04I= Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5e6c18e2c7dso656033a12.3 for ; Wed, 26 Mar 2025 16:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743033451; x=1743638251; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tfL0zZBVe1RxEvNcNmE6dfxCA/2Hz+Ouu0xAFqUlH9A=; b=FvcnxkTvHY/ua1RR8tiXpQgSaIieafQXG4maN4MICHmKsehsf7HddTiXUOMdAVO+lL 4eD8TjnQo9rszSMIgq7OLV4NfhjerLCikX6ZvU3HeTWbEtCNKq2V/CAYyaXdLm3XC65i 388yyWpuuwzlJzZRRYOCr2O2uvgfAHnDOAiFdt1Z477ooh6bVhLe9rmh+SC5i2z6lDk2 BTb/eOCQJr1XvpEEPWuuxqa3miZeQFXj0zWnv0LRleL2J++PsXfAshAA/q/ApvwlF3vs lADRVo5RoIA9HGEwSj1nHIEN3QzFrgwfCZNmcxlJNPH0g4nchXBztyEiko/PPAOhvFwR v1fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743033451; x=1743638251; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tfL0zZBVe1RxEvNcNmE6dfxCA/2Hz+Ouu0xAFqUlH9A=; b=iIwmFGaZX9UXnnqUN+cAg8Mdwr2b8h4o4NN4/DEGaoIauThEnsDawjN2QZKpPL1RRy HROV2wFmgIKeKFXEp9fTvrM1pr8sguHBpNyEd8gTv3zja8zqZ7jqy95+emfNFOOHurDm cc+Ote4qNmu0fATiTn4tuCe7ipV47SGpA7QJ4mN86Skl8ZJMUFO3c22TzIOWjTNIYoZ2 n3JUz/AXJaM8aPxjrtjWYlz0obsBBDIdegHetIx1KDdlPZL3nEchW2QunhbmlLuIV3sA d32707OEk7RO9Dc+PY5WKl+2nM/Nu20f4odkA6oxSQWy3j3IXSbhwX49iSyh42IGeyOV b1og== X-Forwarded-Encrypted: i=1; AJvYcCW7jCCVNrF8i0lznXqov8ivuI2kpScn4tK45s+WMlE6Fj8OXD+2ZjY9XV7gS1hkauTcZuvNhjROKg==@kvack.org X-Gm-Message-State: AOJu0Yzb9QZSz8BxsKWeqxTpqMml2UEtO5SdEGU4vF7zqSeltaGRenwF RmzVSuUU3Hnk08yebj9ulJ5g75vyoejRw6aOJ3BxkGqTQq+0E54BJiqnyTZu0YajxJEZro6fCzt IevjOFMm/+r49iO1Hd8wf/zvc+d0= X-Gm-Gg: ASbGncullSipOWUE0AJOnDbtmwqIZA0iNBdza2XNItIT51vq7BowVjl+nWgAls6Zngz eVstVnfB11Zw5QOTePWEQN1nipnr5Ok8KjQIP2yNSZX9XhY6/Gzj+lns5UDhLskhhB6afM7hHCt F6k/TydSm412FtjpbTZhGonOvI X-Google-Smtp-Source: AGHT+IFN//Xoa5xJhfjM1LYOOVmakekz4BFhgDXTCCePBITSricx0HscPMedKrQZtphZGJnjbaiTDTJRdWnY+Rhiu3Q= X-Received: by 2002:a05:6402:3596:b0:5eb:ca97:7c60 with SMTP id 4fb4d7f45d1cf-5ed8df6a56bmr1585288a12.6.1743033451157; Wed, 26 Mar 2025 16:57:31 -0700 (PDT) MIME-Version: 1.0 References: <20250319071330.898763-1-gthelen@google.com> In-Reply-To: From: Mateusz Guzik Date: Thu, 27 Mar 2025 00:57:19 +0100 X-Gm-Features: AQ5f1JpbmDohO9ocCxEGWIoauJamJ5UA7T8ZC7rvjrjfnqAmW-PgRpsHSi5vYXc Message-ID: Subject: Re: [PATCH] cgroup/rstat: avoid disabling irqs for O(num_cpu) To: Tejun Heo Cc: Greg Thelen , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Andrew Morton , Eric Dumazet , Yosry Ahmed , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Eric Dumazet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 29B621C000B X-Stat-Signature: mcox38gkeb3fpqrn56r8rwn7wh9dtgwm X-Rspam-User: X-HE-Tag: 1743033452-389007 X-HE-Meta: U2FsdGVkX18YNRVmwZfRajg/Zd7dcrHptpF4pAVN5+gx7u7OcNbEhu1A3QiBDqx1cJ1pTXRX2ZmADppJqBWJ5cjs6pvma3yvU4r35BmtXUJaTywfc1c7QjcYmmzRNF02XmQjDEOAuGuz23tn3epkUlXpzXaIAj+btwHL1h2KmVgKQ6pq/GR/u/BhU7DmHMzRHBwM4GXUEaM48V63ODm/ai5b3IxRIGr3NKFD2ugqdsmzMrLzP7lXtwJvhGXgcYsAPhpoZrudpI7VGjX9x23cpR9MYOgSaQiTLB1rPxuXg4wGKlX/RXcJaAhQpb1q5pweqgAe9FFX/ImifMfaOOg0zsX3n7wmC2T2bEF8mZB74Mr0LtCrfyUjfVSwkpC4tDGHElCSwE9G+cNA1k7C6vK6cjr3615hAg50lmiVRiotQpXECXsqZaLkSyUDc3NHId5f57/6aik2xY5YLYfwjPilUK2GtqAnYRbgYB/nnHR1PCDjpqzqJ5FcGiDRy6rG6mwQgjYDt99fYxKjXU42RWni13zGJmVos+1Q+FX/3jY/Mf52n57LJsQ3GKyJvF+dfCmV2p+QIcfUHMyLfF6ZMpfEkjxUXB5IDNVAdzicQ3lUGzc0Bp/t+yBaBrVoEsfSSAzQdOe3z3LoDxyca+5hUK8sH3cMZpyt3qJLF63MRSgZkQIGG+iumFGzqWS5fwaAp7IMK2fEU6FIkgMNHR0n5XClY2YlWlKnB6HVxye+42EoqkAdFa6FXueo3CVG/fxe1J8ZR9TmyGMv3/vCEUS+fx+i0QKt5469P3NCKYUO4agSLSOi2Cb5V/Og+7NxLSEz+0D2gSVhM7IcK3T2kxA3I97A0OiPvqBP8oJTIUTcQUauNHs/sETV18MDAbkP00wzIpKnWdVWUNHlC5H3mDodlVVBsOSsdmH/ub5M7bC51AWTzCnTnriM03r4ostUCVj/X25u8gPCNDQvY0mjbLig3Sn enf3L+q+ UdbpkDmHCOFU3dyPgAY6wbgnNJ2ilT0GZ9eCH2F1p4fM6bHUCGTLXBaYQ/IqlLVsknONo+A4xMaxrdKDljqjdZD5cL6B9cSaCowes326PLNgyE3KxsD31HogQEpd0THrVaJVh+ERjca9gtov1NMyOenU6Ww+hY+fyhtw1sFsq+LrG8Xo2CykmEnSwQ11llJRNfIiaNyQKBQqJIr2h8IWQXwPOhVvuO38K7PLn7fFNt50TGlMMuIwiyQXcXF5veuibNyQDugOMXDPeEtgv4QIVGSNDu1oYpYWKqei6RdrOY+HRqwVA+oHTw+NMIiJZcdF7y9xFvoqWaSBjCxKXkIe5P4N8ZCd4mYAUsx+TDaMcqg23cMsK6V9z5Zz3SpsoAANZHAKzj/3c3IKxg63fxqUf/vOQlnIYzNwtJYOL 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 Wed, Mar 19, 2025 at 6:26=E2=80=AFPM Tejun Heo wrote: > > On Wed, Mar 19, 2025 at 11:47:32AM +0100, Mateusz Guzik wrote: > ... > > Is not this going a little too far? > > > > the lock + irq trip is quite expensive in its own right and now is > > going to be paid for each cpu, as in the total time spent executing > > cgroup_rstat_flush_locked is going to go up. > > Lock/unlock when the cacheline is already on the cpu is pretty cheap and = on > modern x86 cpus at least irq on/off are also only a few cycles, so you > probably wouldn't be able to tell the difference. > This does not line up with what I had seen on x86-64 uarchs up to this point, including Sapphire Rapids, which I think still counts as reasonably new. Most notably I see smp_mb() as a factor on my profiles, which compiles to lock add $0 to a stack pointer -- a very much cache hot variable. However, the cost of an atomic op has a lot of to do with state accumulated around it -- the more atomics in short succession, the lesser the impact. That is to say it may be given code is slow enough that adding a lock-prefixed instruction does not add notable overhead. In order to not just handwave, here is overhead of __legitimize_mnt() while performing a path lookup for access() on my test box. smp_mb() is the stock variant. irq() merely toggles interrupts, it does not provide any sanity for the routine, but lets me see the cost if it got planted there for some magic reason. Finally the last bit is what I expect the final routine to have -- merely a branch to account for bad mounts (taking advantage of synchronize_rcu() on unmount). smp_mb: 3.31% irq: 1.44% nothing: 0.63% These would be higher if it was not for the fact that memory allocation (for path buffer) is dog slow. And indeed I get over a 3% speed up in access() rate by not suffering that smp_mb() [I note I don't have a viable patch for it, rather I whacked it for benchmarking purposes to see if pursuing proper removal is worth it] I'll note though that profiling open()+close() shows virtually no difference (less than 0.5%) -- but that's not an argument for atomics being cheap, instead it is an argument for open() in particular being slow (which it is, I'm working on it though). If you want I can ship you the test case, diffs and kernel config to reproduce on your own. -- Mateusz Guzik