From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (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 BDA172638B2 for ; Thu, 28 Aug 2025 11:46:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756381577; cv=none; b=VjibcyTVBUHbjqljnx3XmXhM3n+stN5pqxZixAKmZVloxv//pMuj439OD0tUw2RWXznT3a8HfDM1bLUXRa4rxpRM4qqlka/oMgtvrr7qni7gE7+ylD/8sLBYEJAUSfAX/6VGeEv7ahs1iKLD+0IU2m5sERNg6eexxoQz8JummzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756381577; c=relaxed/simple; bh=uAGCJDmp6cJsS5qz70KZAgSZxtvKiuj4rYNnVtudL4M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M9dMJZVNHks6OZrGWIJKunaOfQr2MDorR16hLt1UNcPbt/Lhc08QqFWGned+Wm8+41zgWiZ565utJho/7MeYmleLSJvpXt+nskTKxWVdstZrE4c+l3ksH080+3i2D9nfS/fk0RzWYiPAdBtMn1U3RzF1duBCJQ+ojaYJnmKGd6Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com; spf=pass smtp.mailfrom=toxicpanda.com; dkim=pass (2048-bit key) header.d=toxicpanda.com header.i=@toxicpanda.com header.b=gTt3uz5e; arc=none smtp.client-ip=209.85.128.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda.com header.i=@toxicpanda.com header.b="gTt3uz5e" Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-71fd1f94ad9so7253697b3.1 for ; Thu, 28 Aug 2025 04:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1756381575; x=1756986375; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bkW7vRfw5fmjfl6Szg391djOpIwzx0Kzah7uxGUnsRM=; b=gTt3uz5eNf7X1OGusQGWx08Zvs0tFg98T5qv2dZ47hhRP0P/X6u8zsQK2zlACUSOPn 1s1SM/GARczGBQ1vOsAPsjHiqTAKVQ5W06vwjcF9uSD55UalFkoxuH7wC9Tkxw2VQ2N4 ejTi6hDn9z8jrJk4LTSMo4O+2YQk9aYzF0qhDm+YtNm9Q/kHGhTQ6Nz0zvQEL9eraP/i 0DhrVioaLr3HuQ6prYs6YB4RFLkNjVoXUaoOM+8eoMITial9OUF2I0UAY3F5CFBPsSfk wuXK1REf3xGn5U3f7+Pyrzye+yX4P9JmupIsHwb2hnkCITlXdLA990qHCl34ZYK/fPHP p1EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756381575; x=1756986375; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bkW7vRfw5fmjfl6Szg391djOpIwzx0Kzah7uxGUnsRM=; b=OiTYyD8rgkhs58v5avRAKGJ2aw64c/G74il7JtzthYTJkkyktRjD1pzQ3VxplNnkqt nK9nMNyCfGOaVmrDHwxVuKodr+R3z79jKfBEajphEu1rv/xzjSmU4lvZ3lyoMOtP4sWk ZQxJeXNqPvpY+FdsGRCIzqpS+GyDLwWhfX+CF/ECmJpa+z2g6bnqJViQssEN9S0oN57D uPyXlHXzfTN33XnrDCw55Xr/bk27Ns0BrRIfh0VUKL5hCAtNSp50sy+b/kE0e/NzdKxO IBOrAnhOMcEUtZjgMSd4Jyy+dIZTX9Xr5GwO+ILy4Ybh88hyDQ7DgpQ9ctVJtcJI64j9 MIzQ== X-Forwarded-Encrypted: i=1; AJvYcCV15nK/JeC//cWNh8zXvsV/rBRfL9RbMFAmZtSt6DX2oaiNI9cw5vHo/lzdWDvkKmqTewmV6i5YcKo=@vger.kernel.org X-Gm-Message-State: AOJu0YwSGkOftejaOqIV6gwc8wCWq5LnxbQ8F7F/9UfRBhRXskQVAUxA 0S6Lv3UgriEbMowoXjZ+9BXJz5h9MBMMZP8MBdvEQgAqo9gXSniX+NMWQGB7XldZwws= X-Gm-Gg: ASbGnctGScZx0DlMc2+YC4xwGcVXPe7Vhc0jWkp2wy9DPMInaQqKSRWpAIWljX5YP8M 259W3tQqkYy2I3rrLMyxWcoodf4rmBaG/XKw/ivjtnpHLwp53G7LwdyQInc3Vf/7bmtYJXt1Xg5 h0JvogKk2bz6AG4b8ZbSaROTqHkP9fgoSgiwVEeKHZmWpW7LOSjWs149yCm/GPUJWq7BLNa7eMo y376wAOCQXgS/mXtdlQRPpmBUtgTMAK4jm4nxR7m2pHp/iqrn1l4Neg/6yPDbthxaOxWu3S6qSM 7CtC2iIVxaNtx6CXoHCZLJAThFiMHivy/xs5f3iqxpP8/oKAjhjhUsD4oDp3RVwNukbDz+ZeVq9 sQU5F+xBnZDUC2CxD6KYrMbzSY7snei4SmOHAQSn1aGQc4+cINvkdi6icUKAEUIpJFEjGrg== X-Google-Smtp-Source: AGHT+IEg0qq6vVFcC8HtHbolYGh9JI2dm7wBds4DDkIYpwL5F/tmw9T7MssYibXngJRFYi8Fu+PtoA== X-Received: by 2002:a05:690c:c14:b0:721:6b2e:a07f with SMTP id 00721157ae682-7216b2ea4cfmr2820057b3.24.1756381574661; Thu, 28 Aug 2025 04:46:14 -0700 (PDT) Received: from localhost (syn-076-182-020-124.res.spectrum.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id 00721157ae682-71ff17354cdsm38508237b3.20.2025.08.28.04.46.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Aug 2025 04:46:13 -0700 (PDT) Date: Thu, 28 Aug 2025 07:46:13 -0400 From: Josef Bacik To: Dave Chinner Cc: Christian Brauner , linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, viro@zeniv.linux.org.uk, amir73il@gmail.com Subject: Re: [PATCH v2 17/54] fs: remove the inode from the LRU list on unlink/rmdir Message-ID: <20250828114613.GC2848932@perftesting> References: <3552943716349efa4ff107bb590ac6b980183735.1756222465.git.josef@toxicpanda.com> <20250827-bratkartoffeln-weltschmerz-fc60227f43e7@brauner> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Aug 28, 2025 at 08:01:39AM +1000, Dave Chinner wrote: > On Wed, Aug 27, 2025 at 02:32:49PM +0200, Christian Brauner wrote: > > On Tue, Aug 26, 2025 at 11:39:17AM -0400, Josef Bacik wrote: > > > We can end up with an inode on the LRU list or the cached list, then at > > > some point in the future go to unlink that inode and then still have an > > > elevated i_count reference for that inode because it is on one of these > > > lists. > > > > > > The more common case is the cached list. We open a file, write to it, > > > truncate some of it which triggers the inode_add_lru code in the > > > pagecache, adding it to the cached LRU. Then we unlink this inode, and > > > it exists until writeback or reclaim kicks in and removes the inode. > > > > > > To handle this case, delete the inode from the LRU list when it is > > > unlinked, so we have the best case scenario for immediately freeing the > > > inode. > > > > > > Signed-off-by: Josef Bacik > > > --- > > > > I'm not too fond of this particular change I think it's really misplaced > > and the correct place is indeed drop_nlink() and clear_nlink(). > > I don't really like putting it in drop_nlink because that then puts > the inode LRU in the middle of filesystem transactions when lots of > different filesystem locks are held. > > IF the LRU operations are in the VFS, then we know exactly what > locks are held when it is performed (current behaviour). However, > when done from the filesystem transaction context running > drop_nlink, we'll have different sets of locks and/or execution > contexts held for each different fs type. > > > I'm pretty sure that the number of callers that hold i_lock around > > drop_nlink() and clear_nlink() is relatively small. > > I think the calling context problem is wider than the obvious issue > with i_lock.... This is an internal LRU, so yes potentially we could have locking issues, but right now all LRU operations are nested inside of the i_lock, and this is purely about object lifetime. I'm not concerned about this being in the bowls of any filesystem because it's purely list manipulation. And if it makes you feel better, the next patchset queued up for after the next merge window is deleting the LRU, so you won't have to worry about it for long :). Thanks, Josef