From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (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 2D9A4305E19 for ; Wed, 27 Aug 2025 21:47:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756331224; cv=none; b=qeR74WN5Ydai58al0Qh4Sw3tBbmA1NWmlVAApprsYXKJAxLd9LmGEjdZzq0npA8rf02ZFBYQ13eytk9hvL632LvpRGMX4h/dU2NSmjyDSUqAnbOntVaeqkkW132cYBU3wTI6ZS260wqP04S7mpHLbH2VlP0fmI9BNkkG1fQ2eI4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756331224; c=relaxed/simple; bh=p7brPDy2olHFfAC7S4q3Vp+PKM6Nm9aH82XdvCJ8awI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vBvnzihatQJJ1yYk3ixRbCQj9WZHibGQ20RnmqLRuPB71YMljjk42uwCLCX8hZCSYaQ6jK/EmO89rIrZmA7U2D9ic7X2mhnfCdBsFI+x2/zDgwR6K8s0amJiVdhtap5HO/RhA3QUESQCId+RW4+FS514KFwIZ07MaJTldUi9uiI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com; spf=pass smtp.mailfrom=fromorbit.com; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b=oTmL/8S2; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b="oTmL/8S2" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-7720c9e2900so445930b3a.0 for ; Wed, 27 Aug 2025 14:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1756331221; x=1756936021; 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=1brA+k4hD/Yqcu3E+OzWK4Zw3vVchK7SPI3ZmUa+ClY=; b=oTmL/8S2U0QYx+4QQGCxzpTYxxbY2M847yIFjACe3uxKSxUtpm9qlqz7Ets000hEGT eIlJIh/5HkEN4W8yhMs7iQIcBBI8FCGR6qgATvk8QiXPmAACVNI2FuqOYKsPDLtIC01u W5n9bD10pqz1hqvN39di9RF5l7AwgDEZevx+3g0lZpbypK6Mg9oIF2eJWXPanYxofjOF sfFkKPdVPpnOU8VyGa/MjGDpJYfJSq4ccjwXjn9iBdSNAR9wIaImSVISg9EHkTjc4TcF aqb2Aygkz2vYxwm5obVtQ60Ayx/IneMQkZDZKAS6Fg/q94wLCXZAqV1rvfPcFRjB/hBz ADRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756331221; x=1756936021; 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=1brA+k4hD/Yqcu3E+OzWK4Zw3vVchK7SPI3ZmUa+ClY=; b=h2aJHg0IESsqz/5mvTGqiZRZcvg6Nprr48xgSJdqDPOXmBd2OxM7Kuxsbxhklj11hp cLLI/aYGcRaP3jmx6eZwvs3Sjq7ZSr0pnYVogAqVfVaPYd8g4Znt+j65B3L8MiTuWfK6 MRkNtCY0XMJ4FaaKMroviI75c9YV81NZD1QJf91MJMcapuIn2AoHHtbPb1+TZ36Ez2R1 XKDtrlDR72HLjjPkQ7joJ5L9BPKylOkGn82YJJWutacRhBaB13GqN9M0kp0V1S8C+Ftm v1xpYmlL+phgdQEM7esUEX/qvM/NZYLKOsjSeB+XlByLGlTG5bP/mPhxy9d8L6zsu+7/ OF0g== X-Forwarded-Encrypted: i=1; AJvYcCU9OL1/IrttpriLGZFBgKD7XQxZk8Nq8f6eyu5sVcrBtKcfX4P+d9zSOc/X7UUzb56oGuR7nSrGeetc@vger.kernel.org X-Gm-Message-State: AOJu0YwKtHvF9Wy4qo94ZyeciFz8hvT37Lzp8oLAJDU1XqCs2gftL5cE 0z1yDBN80ZwYnVfu02CLRd57I1QGC+PYiNrlr7ZjYdaig6SwoS7VOiLs5q2lzGPZ8lw= X-Gm-Gg: ASbGnctQTeGZ/adv26Du/tyiFTaYUd0N8zRVJJ62HueDNsvWAb2W7GAv3rgJNzlIv5j zj/EHU4XZb86zU2+ivBxqt7Q29cyNPhS6KGSZefwRucYMtgRKkvMILefRafDrMSCSJJyztO5GB0 jRx1LLDFcVcXRBeYbJNngWV8F7kCCjjrhigpIJqfkP2tWwk5c8+FL4q0A8xAmB7EY9MxWCHidnw mxIWYZmra7cMucE1IBxadhOHuWMx1KQsFmSlJTQ8ncs04BJ24hsxANGZSCxvTb5bKgYVSXch3PN jpE0SZWNYzVY16Cuhhw8VrdCfULEp+xU8HsrfUpVUdCx2ex2YEmQFyMuTB7jZi6hfSSybCroMnI rBFvrN9YSLSXDsiXHZmftkaNiSOih586y7CZInThx6aP3o6XmoBgdAgSvbZe+5ioAsPAQEW+lhi TjqbI4567H X-Google-Smtp-Source: AGHT+IGwubMhrkeveyZScO9SyGs6JfX0VeRusyOBY+29aVn++TMuUkFVK5pCfTn+imoo/NPkWa8qcg== X-Received: by 2002:a05:6a00:14ca:b0:771:ea86:3f73 with SMTP id d2e1a72fcca58-771ea864584mr15877772b3a.32.1756331221445; Wed, 27 Aug 2025 14:47:01 -0700 (PDT) Received: from dread.disaster.area (pa49-180-91-142.pa.nsw.optusnet.com.au. [49.180.91.142]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-771f34ecccesm6566839b3a.61.2025.08.27.14.47.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Aug 2025 14:47:00 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.98.2) (envelope-from ) id 1urNyr-0000000BvQF-035E; Thu, 28 Aug 2025 07:46:57 +1000 Date: Thu, 28 Aug 2025 07:46:56 +1000 From: Dave Chinner To: Josef Bacik Cc: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, amir73il@gmail.com Subject: Re: [PATCH v2 16/54] fs: delete the inode from the LRU list on lookup Message-ID: References: <646d132baae6e5633064645e677dada101681850.1756222465.git.josef@toxicpanda.com> Precedence: bulk X-Mailing-List: linux-ext4@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: <646d132baae6e5633064645e677dada101681850.1756222465.git.josef@toxicpanda.com> On Tue, Aug 26, 2025 at 11:39:16AM -0400, Josef Bacik wrote: > When we move to holding a full reference on the inode when it is on an > LRU list we need to have a mechanism to re-run the LRU add logic. The > use case for this is btrfs's snapshot delete, we will lookup all the > inodes and try to drop them, but if they're on the LRU we will not call > ->drop_inode() because their refcount will be elevated, so we won't know > that we need to drop the inode. > > Fix this by simply removing the inode from it's respective LRU list when > we grab a reference to it in a way that we have active users. This will > ensure that the logic to add the inode to the LRU or drop the inode will > be run on the final iput from the user. > > Signed-off-by: Josef Bacik Have you benchmarked this for scalability? The whole point of lazy LRU removal was to remove LRU lock contention from the hot lookup path. I suspect that putting the LRU locks back inside the lookup path is going to cause performance regressions... FWIW, why do we even need the inode LRU anymore? We certainly don't need it anymore to keep the working set in memory because that's what the dentry cache LRU does (i.e. by pinning a reference to the inode whilst the dentry is active). And with the introduction of the cached inode list, we don't need the inode LRU to track unreferenced dirty inodes around whilst they hang out on writeback lists. The inodes on the writeback lists are now referenced and tracked on the cached inode list, so they don't need special hooks in the mm/ code to handle the special transition from "unreferenced writeback" to "unreferenced LRU" anymore, they can just be dropped from the cached inode list.... So rather than jumping through hoops to maintain an LRU we likely don't actually need and is likely to re-introduce old scalability issues, why not remove it completely? -Dave. -- Dave Chinner david@fromorbit.com