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 2A703C30658 for ; Tue, 2 Jul 2024 16:47:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF30F6B009E; Tue, 2 Jul 2024 12:47:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA3346B00A0; Tue, 2 Jul 2024 12:47:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96A5D6B00A2; Tue, 2 Jul 2024 12:47:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7414D6B009E for ; Tue, 2 Jul 2024 12:47:34 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2D332A0326 for ; Tue, 2 Jul 2024 16:47:34 +0000 (UTC) X-FDA: 82295393628.03.8E9EAAD Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf27.hostedemail.com (Postfix) with ESMTP id D85F840021 for ; Tue, 2 Jul 2024 16:47:30 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=UGB1Cbnn; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719938828; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UuomGKlgZ/JCx5qkaXWQw7kYZlgSwRcXF7z8kwqPXBk=; b=r455qrclBEp7iG1usCMZBeKeYjPaUkGmVOWJntzTH+wEn+yOZVyrWsShFfQCi93v9KvFRX d+x3KzV2/+gbspxepdIQ7qJI8uwCYqnUd7WAd+7b/wGtJ5yf35G0d3qvYmYS1Pr/ROfW4N WKajFMMAKhNrd07nNEfDsmMV+WIP15E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719938828; a=rsa-sha256; cv=none; b=KWQuJL4cv5xGJ8YJ4vKrdzdCecgw2fBF1kmF2D2IKghOCQY15tiMFbCBLGDelSLFc1WCKh zD6ewfCZtIXnhkJ/W2ya4G9Y55W+kSZpUby+D7rYA7mNupGXxwowmINJdiAa6ya64Pwkxg 02xSWSYEMjQF6H4cWPa4E69WhoYuMu8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=UGB1Cbnn; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-5854ac817afso2271457a12.2 for ; Tue, 02 Jul 2024 09:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1719938849; x=1720543649; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UuomGKlgZ/JCx5qkaXWQw7kYZlgSwRcXF7z8kwqPXBk=; b=UGB1Cbnn+hV9nUvJL4h4klzbHags9UddaJY2QpeVkjytt9MEqz3WQdS2dh/JBeYB/R iV5wZoSWv1xmHVgMNhgyqKirEaZjaiIzgvJ3c9ul0KC1KLN8kXjD82JHAiFp7kXekWaS vluouTY8IJH19d1p6j/rbljCktHCMg9Q3neDQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719938849; x=1720543649; h=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=UuomGKlgZ/JCx5qkaXWQw7kYZlgSwRcXF7z8kwqPXBk=; b=L0grTZyON8I1jZ+uAjPQFdn8gJvjjMZNM0AlnP4dWCJnEDDO8CD8q5dPElkWVcdbDm BIgXSuZ1Ava3Gyk5mPkRlhnDFx8VR5HaVuLDDWIt/VzAeGsnyuTdhFy1onK1aE9mWBBk w/lPpr1ef8UT22fbf6/X6cPjiv+gf+3hUdf5XHpqKIHWD9Sio6kVjadEgim2u30j7mf5 8+HjrMnFYAhDgG7EFa26/Tybeimr2zFHMWX3UiKFOhpeCpgF/KkSc6xjkc8efcGYYVlR V32rfNzuCPGnDr5ueiPbytfOGZVKDo+3tScCwHamo1cf6FhIhLW9/y07raG8cOdwfQhx YsbA== X-Forwarded-Encrypted: i=1; AJvYcCWyCMmAcIpEn5z5zJgvFLZpKSJ3Amuf0bPHGcP7A2B4CuYdOYJKXRl+IvUFULCdfXazeP6qC4n/EJ8i1W3BaCdkrW8= X-Gm-Message-State: AOJu0YzEbHmCA8/QEB1URi+zjHFprLpwW2k1WsvSpq9r+FRy7MsgUc0t QO9Xb5UyeTz7X4SCbolMT/HUTFJHWD/9k1cSZKLck1wqfVNW41OpiQJHibccFqh10ZIz8c2W1Nc CtWmVJA== X-Google-Smtp-Source: AGHT+IGg3awcz6V/r6Qj97xTV5veSXkFRsC35KLIc4OwrQr9LkNENt6HRSIFTThTqIMvVv6SmIx8EA== X-Received: by 2002:a05:6402:26d3:b0:57a:2e93:fe80 with SMTP id 4fb4d7f45d1cf-5879f59b6c7mr7990516a12.18.1719938849010; Tue, 02 Jul 2024 09:47:29 -0700 (PDT) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5861324ed2dsm5910793a12.28.2024.07.02.09.47.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jul 2024 09:47:28 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a72510ebc3fso660669466b.2 for ; Tue, 02 Jul 2024 09:47:28 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWbb1riu39quGKPmO9ls06QNg+5yBlgiFN+CgZVGwGT9YNT3qCazkag4nmAKiO89/bAUbDorYSTok9EuLZywtnFIGc= X-Received: by 2002:a17:906:c2ce:b0:a6f:493d:5b9f with SMTP id a640c23a62f3a-a7514474146mr573370666b.35.1719938848162; Tue, 02 Jul 2024 09:47:28 -0700 (PDT) MIME-Version: 1.0 References: <202406270912.633e6c61-oliver.sang@intel.com> In-Reply-To: From: Linus Torvalds Date: Tue, 2 Jul 2024 09:47:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression To: Mateusz Guzik Cc: Christian Brauner , kernel test robot , oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , linux-kernel@vger.kernel.org, ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: o5kig385569yu8oqtkdbtuyyywqf878p X-Rspamd-Queue-Id: D85F840021 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719938850-719199 X-HE-Meta: U2FsdGVkX180hoAu2BqQ7COmpoN1ztFSeqM85ES07uj9sbC5pbVnk28NsCV158Y2bFqQp2DUK92rJQFp98s7hXyt3+Qh7DxrSJxMabX9Epqk+/pUQu1tcCNTCyX+jQ5bi85fgW5LyZcxP/Lw0Kpq7QJTlmzGFHhTBQvA73n3YNSNRfZ/fC+Mp92cfZKjubQVNiDXoz3hX004k5X6u/0hxQBavpILqHruc2sAjUhhyZSX6JUe2YV1Cp5nNRZXcCp5fljVQuFkteo8FPt+HE5uituoKGpO31Pc2t2SXs4HM+imIB+AAN4FJEjbKM07anKSIgQwYhU9TD8pwcp4YQYPmznS6avbV6l7KVCI130ux8nnsTwoAKdPIVs6gN8V5klVtYbH9yBxMHJDMqeFUTEyMZV1gbxo25txoWl6NKUitCdM29Lkt0OplqSMcberz0BvQi7jnFpfHQU7OreQnskQEA6FHw2/fxBmaUmGRC7FS4oTZYP2fX+JB0dEWbjHxp5JGT3BSMl5Gf+Wf/chUpFSvU0xVSUWQwdX4gCHR7fGIGvxeolWwOwDq9sPqqlCZvS2Rrz3Aoq2Qx5UephpcoHIoIrXVTITuN04/UUuyrYq66pyVr6ka92l5tDVDW7YIhl1BMLecgw1tfUPR5HzVihj26JIkca6gctjEwHb084nR03J+IiAQGQxe4z75VtWnYtMV12Iye+L3SFweBoxPD2N7laU1KKGPCLfVucTf9rf77c74UhUAlJZLd4bx3UtMUt8FlNf8ss8oRA9CdqLptohqsHSoP9QBG6CBNxRDAET7CzKYjomJFPmLNUDQrNX5hqngkz0lXCmbOX68oH8AjDhu9xzweNs2erc6VcJAMJgMlIl6WRJT5wxqmCpsjkqbgZ+QvRazoFDC7GRm2PRFXW/QYfq7vRG+6CqH04inzdX//ohp2OhY7jyfNqzAPQy21TFV+cm/FPgge4DaTOYpFP 7N5ei2KH OZT6xjfYicmonUL0Im8DlCJJSS55J8rcCqcPUrVjSYFmrEKUSRDqSlmUKu3up7Uhqzx9YIJt3g6zYwu9+14V5hYCMHGBW9i039zRSL5lyOuxJVOfJN40kI0NejGoKL+Q1o8sgRrgCHYkvBKSaSiCA4NGdzQ53dg+REnncBKGVO8UlDkSA1F9bsmd637YMtStG3un8smnPIKnUsTFCuIwADC5B1Q3BNyFugi+qx5XJ94df6ykXs8PUFsxKMQrPIN4c51ImNhlRZ6wcny3wepVSldLZjG3oR7EJCTR4xbgQhVCNqbJIjoJnnvn7NO2QBHVu9HF6Dvbc4tX8lHu7l5hy1To0qVxn975K6P0TK/+/gObyxBzolrvo7Mn0lKgE5wpJqW3lbSBH/bYgd8NpqDVcYjXhmVGvatfTw42pANEfZwQq9aTvHQV2lqUgMcL53bUYgw3AWNH+VLQFnUjviWjlGTcGwhiO8nUY1aSh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000047, 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, 2 Jul 2024 at 05:10, Mateusz Guzik wrote: > > Well there is also the option of going full RCU in the fast path, which > I mentioned last time around lockref. > > This would be applicable at least for stat, fstatx, readlink and access > syscalls. Yes. That would be the optimal thing - have some "don't take a lockref on the last component at all, because we will finish the use of it under RCU". I looked at that some time ago, and it didn't look _horrendous_ from a conceptual standpoint, but the details just got to be nasty. What I wanted to do was to hook into the "we're still in RCU mode" with a callback that stat could set. And we'd call it at complete_walk() -> try_to_unlazy() -> legitimize_path() time just before we do that lockref_get_not_dead() thing. So then the path walkers that are ok with RCU state (ie mostly just 'stat()' and friends) could set that callback, and get a callback while the path walk is still in RCU mode, and could fill in the stat data then and say "I'm done" and we'd never actually finalize the path at all, and never do the final lockref_get_not_dead(). Sounds simple in theory. And then when I looked at doing the actual code patch, I ended up just running away scared. Linus