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 2D525C30658 for ; Tue, 2 Jul 2024 17:46:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C1726B00A3; Tue, 2 Jul 2024 13:46:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 971636B00A4; Tue, 2 Jul 2024 13:46:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 811E66B00A5; Tue, 2 Jul 2024 13:46:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5AA8E6B00A3 for ; Tue, 2 Jul 2024 13:46:56 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F0EADA19D6 for ; Tue, 2 Jul 2024 17:46:55 +0000 (UTC) X-FDA: 82295543190.11.9628446 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf26.hostedemail.com (Postfix) with ESMTP id 8BB2F140010 for ; Tue, 2 Jul 2024 17:46:53 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cq9xQAnc; spf=pass (imf26.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=mjguzik@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=1719942390; 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=I9LudFqvhzywM8+PbU1gzhtr4RCksBJHHLnpxcJPyI4=; b=eihLo6RGa2N9z0ep/lxgqqajLw14+cLZK1KpfSLed17m6+v7t6z/Uj0fLhfTZJJh/r4IYt IxNI4+mOgYi9lYWvM/bmUmOYioGb6Cp/JlvX89NFhddpwgaYwozu2fYO0VntiogEaIvUMW /tGNS5pqM5duxOo8HUZU93ZyuWHMrZM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719942390; a=rsa-sha256; cv=none; b=xFycHD8OTZkQqpFrUFSGgCWvAcmdGg3XTjP2z0oAahovE5Lb+IOklL1net2LkOJEVWw2G8 1APJZAVnG9bYbPN0g8a4aXroTExzEN/cpjx4LI3Yp6HXjMQaR6+WjLwLXLxi0FjU1fAY7f LWUUinxMiR65EM8pLLq4J90OMnb9quA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cq9xQAnc; spf=pass (imf26.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-52e94eaf5efso40933e87.2 for ; Tue, 02 Jul 2024 10:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719942412; x=1720547212; 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=I9LudFqvhzywM8+PbU1gzhtr4RCksBJHHLnpxcJPyI4=; b=cq9xQAnc5AV4KfQV9s4fjMHqgZl6ddZuowgD6x4yW6r/oVofLyfVk6vED7vwR8O54t wmDl2oCJbW+eWRkVPES88O/S2Z4MWhzk7nOIqhDAszOFhdRrbgX9JW0PYtMZxW+ok7WL AV+QquQEQZmifMVbgPw7botdmExeoszrImp7dZw2aI3ipTA1YrCzRthG6yTsL+4PC1CU fjRJmyG+gGaf2tAn6Yp2K8LCPn9JYtFP3e9HNRVFksdEKCVdn68Iq8rxLx2qKjbluzDV OXvTySi8b7fndUHvJJ1AKIVvTC0J691HXRbqt2u3lKhw0uS0Pepxpx8E27sVjdzAFfmh mVIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719942412; x=1720547212; 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=I9LudFqvhzywM8+PbU1gzhtr4RCksBJHHLnpxcJPyI4=; b=MYUwzgQHdQbFAhqCAqJAdAp8x5fCJqf3/zV6VRzJ+XXBB/rYs/BibWAsKmSkA3f3wj Z1FllU1jLPdtxz1W2wxAf8/7i3zfwnb8UirTDMrqZXObd5BKGQXOzQJ7zK1ML3GGRR99 ppPpBB0iBBP6yC9IbGLteh40/TwrqqUFHJ1skGFStkDuJoG/UTToeratVA0/9HskFVKa CkV9Zg96ibpVJhKxnP5B5rnMvWmdWFLAKJmxtwhZzzoZRMOaZFRdLQNXgLkKNE3Hhp60 lJgFAEzNokvGorOzYF5hBkfrJPMwB3x+czt93muLgfB7KGM/DOhK7uu7el0EkpgtdIJh rXWw== X-Forwarded-Encrypted: i=1; AJvYcCX2VHEh6sGf/lebCWoZna2UOjIMBs4zWDcbN5qu0Fcf62yuh+UgFuI/r3Xz+d8rwzJdDwiarHXNJ6ZgJJCO8VBUrM8= X-Gm-Message-State: AOJu0YzJhw5CJVPKzU2uqZfybcfHtcrJXw23ZoWUoCwC/cV9fLTGpf0z abJcuY/BlIo0hSme+hBAgNXCwaKd1+Wb5nzKRCut87gh2rxfA5d0omY6SWQ4MWWjiW92uFhWeA4 Y2AwhKkm23XF+ONBX/lrb/2cDztA= X-Google-Smtp-Source: AGHT+IEBbZsL301fTpokOmoMZTiPUizu1JrFyQ0P6YdSWvW3tyH2OnxtLZJKdilNRvkgjMEV5fLXKoBYn3fajVYprKY= X-Received: by 2002:a05:6512:234a:b0:52e:9471:e54d with SMTP id 2adb3069b0e04-52e9471e73dmr138254e87.65.1719942411502; Tue, 02 Jul 2024 10:46:51 -0700 (PDT) MIME-Version: 1.0 References: <202406270912.633e6c61-oliver.sang@intel.com> In-Reply-To: From: Mateusz Guzik Date: Tue, 2 Jul 2024 19:46:39 +0200 Message-ID: Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression To: Linus Torvalds 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" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8BB2F140010 X-Stat-Signature: wrmf9xzt86wndec9s9ep7iou8d3nw5ox X-HE-Tag: 1719942413-302395 X-HE-Meta: U2FsdGVkX1/+FhkTS3RE3y8ix5gLY1VCi1iMAn0RYRYVEIVUdIDV8fCF8vylzd4+MB4bhHlzKNV3n3cG/+kY2qGi+/DGsoJVMFfWfsbZejNEUz6FP2rgK8EC5Svxv7Mrm8DyTt7bX3qfG1mLc4xltfCuZR3/l1Xkv8lSaUhSTDREUXjirAwqlkbm00lw2U+hAiXpoUWJgCXcmn5Qdc59h8AJ58dfiZbDyxw51LTENsDmrm2t23HejMn1yN/mt+4E27WQYCu1b9H5agYGxbj1GADACC4pYbird88eKL5iaR7HD7+SSABkuF1Vmbw5yu1/bZej1zhWFkNZcpSU0gwRQ0wRV85VUWdqXpWexbo4Jy1pBBt1r0zHegJcPRQ1HGwWUQYwUQ7K9yujVfEzeR6N50zKsarcB628tiKUpfsjrcZ/NLuRe94vGVeuWynQ481y7Hrcu09Cbt7DBAAAQzhP+DsxQJkIJmjGWx+WkC3/pFyHHTs1moZ2GWhRcdE3YQ25LWjhgBs2KHamV9yTgY8yvBKeM1br10i9+o8yIHum1Cs3zE6V7M9GtGPq8kK2dA7xuuZV/iSaGMZq3+XadQjK4/xLDI2vwlFsBGngclCsKpZBYqKEdBukX6CKNrR5pCJmhsgvGEZKhykjPIB/7dtuDjwCzxEq+dkgQXAhBG/pq+ulFV3bEG+XJV/58O4QB2TaXwy8r9XGYY+9Q/amYZqV7Amj44Pi075+WXBrDBL5qJtLufDd9NWwWgy1hLnRL/V9VD1VBPxbeqJYuMeRHwGyY9Jtzm2Ma6JaqjRy+bU21q7lu2cRrwhSebTbDTseaEEFrFjcEfUgItr2r1b8Ny5IqK0kUhii9R6VBrHhfiEuO/iYQ7NVNS6ZQyerRMyeGeitzVrh1mYtjbkokkzfWnTCU49DIUo/SDROo98Br7/gZQGY0rpb4k2V/3xA8ean8gADXoJYyxt89D98HUVwUuQ rqYTrIOy w3xpuPKZeM1/fjkQfXw64foYTkXK5YxowAt2wERxXjwPjpq019zKgKWZUV0dDyigVWpiDxhVcuuC66PMT7hBN0b6OT3kkARr5vkZkUuzO63fgZ0Kwq4fzjB0dhT3Fo0vg4qo5YEZq7d6bfMLC+FODXZQRhzb712h95OmtzMCfoOlIrmAtADLSx6+IGxswSYc+jVvRca1T4I7lRe3Ozd7BvRxa8Tva8Jrp9hIHtLbfOG6Hhj0T1U87uEg1u9wL1cquUyjnufiDSQx7NvwSJB5Bhxy7NmKnWNMMKuyo+NwiOtfrfgW8SiNiwRhjmjIRycqm4brAERheh3tWTV5KDFXzTpbUufNykGNTq2LgY2S+VpzpSWSnJ8oM8Bjx9rynhB2NoVIu X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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, Jul 2, 2024 at 7:28=E2=80=AFPM Linus Torvalds wrote: > > On Tue, 2 Jul 2024 at 10:03, Mateusz Guzik wrote: > > > > I was thinking a different approach. > > > > A lookup variant which resolves everything and returns the dentry + an > > information whether this is rcu mode. > > That would work equally. > > But the end result ends up being very similar: you need to hook into > that final complete_walk() -> try_to_unlazy() -> legitimize_path() and > check a flag whether you actually then do "get_lockref_or_dead()" or > not. > Ye, the magic routine to validate if you can pretend the ref was taken would wrap it. > It really *shouldn't* be too bad, but this is just so subtle code that > it just takes a lot of care. Even if the patch itself ends up not > necessarily being very large. > > As mentioned, I've looked at it, but it always ended up being _just_ > scary enough that I never really started doing it. > I implemented something like this as a demo in FreeBSD few years back, it did not blow up at least. The work did not get committed though because I could not be arsed to productize it. tbf if anything the only shady things here that I see is that stat et al do their work without any locks held nor seqc verification in current kernel. In FreeBSD this was operating directly in vnodes (here one can pretend it's inodes). In that system I added sequence counters to the vnode itself and any state change like write, setattr, unlink or whatever would bump it. Then something like stat could safely read whatever it wants in a lockless manner with the final check for maching seqc indicating nothing changed. Not having a "someone is messing with the inode" indicator (only with a dentry) in Linux is definitely worrisome when pushing RCU further, if that's what you meant. Again, I'm going to poke around if only for kicks when I find the time and we will see what happens. --=20 Mateusz Guzik