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 671BBC47422 for ; Wed, 17 Jan 2024 19:39:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E04B26B008A; Wed, 17 Jan 2024 14:39:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB47A6B008C; Wed, 17 Jan 2024 14:39:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA3C16B0092; Wed, 17 Jan 2024 14:39:20 -0500 (EST) 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 B9C356B008A for ; Wed, 17 Jan 2024 14:39:20 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 90DD6C0C17 for ; Wed, 17 Jan 2024 19:39:20 +0000 (UTC) X-FDA: 81689816880.04.313B2A4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id D311B160007 for ; Wed, 17 Jan 2024 19:39:18 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=orRxnePz; spf=pass (imf08.hostedemail.com: domain of jpoimboe@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jpoimboe@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705520358; 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=m+NXdSEy24MzzjJbAjnoAHvAlL54I+uQnSKJdE/tLFE=; b=tEvsPGMfDRQmGggWJS2/BEDUr18ETMEPmZ5OHo+bo6nW+nZuDPmA/UvhV2kbgq0l2D42wT zqQMmWmvF8ig+zh1P4lB7TJKclCWfnP4VaMMaTWRwpLBR4kSncQArxTgK+IgkQ4O1NdY9k XPJh7rmhShPzqK5Ieu8nMiFTBmlkbNc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705520358; a=rsa-sha256; cv=none; b=HkmQDCpOd8NeFAGOLsQnKdSVZFXLkml01T4Vrcr/j5BM/8F9Mq3rTvqE0MgjqKpHZTGvay ZvEm/MFBRqBiOtjwESoolZKXzUoaj0JwNzJEpV5/hYqAd8qHq3iafqKdYqylrurXMzsqTK OPIzx5CYBvu3Hdor5YZqXS4PUI0Bddo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=orRxnePz; spf=pass (imf08.hostedemail.com: domain of jpoimboe@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jpoimboe@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DB69E6158B; Wed, 17 Jan 2024 19:39:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E773BC43394; Wed, 17 Jan 2024 19:39:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705520357; bh=qqBJ5vug6dV0ozKgqcaIGBYDgv7KtCxfYMh7ZJ6Q26I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=orRxnePz8lKyXr+Shhml4pKgH35Jq98oR0yKMRCVSvRdPt89dqd8YD1EAaHH1FYAo b1YS475T+RiWVkm65+l4ip+ukCfn8tdioNl9nx7fpInQeLqC9Nrzwn/lM2rZy8WKPj nq8961EIaresqnhqe0wVGapP70T1nfuuMAZIjubxrsRn/dKoqMlDmIr0LdZh6q8lIK 8w7wMv9952y1yVGe8dIIeBKka/8Yag8C+MpbiU/3ksYdDz2CYgVJ0/eBB9qT4Y/DYl Y2q71urfRZ3QKbHNM/0VzD/dSKy1cYDJv7gqZzC16eNsvtbxduiSLAEEbcEhbHg7A5 hBWLDtV0WGlzQ== Date: Wed, 17 Jan 2024 11:39:15 -0800 From: Josh Poimboeuf To: Jeff Layton Cc: Linus Torvalds , Chuck Lever , Shakeel Butt , Roman Gushchin , Johannes Weiner , Michal Hocko , linux-kernel@vger.kernel.org, Jens Axboe , Tejun Heo , Vasily Averin , Michal Koutny , Waiman Long , Muchun Song , Jiri Kosina , cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 1/4] fs/locks: Fix file lock cache accounting, again Message-ID: <20240117193915.urwueineol7p4hg7@treble> References: <6667b799702e1815bd4e4f7744eddbc0bd042bb7.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6667b799702e1815bd4e4f7744eddbc0bd042bb7.camel@kernel.org> X-Rspamd-Queue-Id: D311B160007 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 67bamyd75wgurad48qrchhxqp7ru7dsn X-HE-Tag: 1705520358-958791 X-HE-Meta: U2FsdGVkX1+n16ChP581FMMNXT7gFIeyENb/ah/IsBd6EPLKB0+z8gXxinA+5SyQ/zcecQGNAjuR8V3JnD48oOTnec0JEGpISn4vpklJUeDEiE3VsimUW3Q/Xxmi61yLyqzO7oIAJI9LjI+D9ImSijBx1BWDe+NzTWByvrp2Z4JgpxONtUdTwROy5IhSXwK6XgOKxZ1eP2iBbm6qleYIbJ+vG25lB1Vun8PqVkRp92SLMpoIsLeVpoRU7AT/iUQCfLs/qs3NaOkB8oX2QtT19sw67aEueogqXsqbb/sM+YJ91CSIlNFZ36p70y2cdS9ACiRc0rf3W4i88u17PsqA+7uuN7SL55iuaTHkxYWzkmpH+asWEwe2MnNIRjG86TMA/A37G42wp1Khx/j61cq7EBLAiuPkr0UXNo5+AVbtFSQpzm/gNN6fhbHXNvNIUOuwQV4AeYquC7zQhtroaCOejIbdNOYf08mq/UFfgbJ0RDpOFGj3H4S5aZNp9VaEYU8xvJ0BBN2vDRdPaKa9tmnpPpQl4rLHHrVSw6n7owx6z6Szk8O7Ekm3sNDm1ry+pBX5l3anQOy7bd2uNrGHQKr/bxM1bBGM8rrzza3nzwr361sNbHWJMM0s/g+Gu/Wovk/us1BBGfcr+yE6it9r2PzwbxBeleuuk4YWTQGGt5FQe1GSj0Mk+jR1eya1gvz88y7pWkRA+ASuRQNOuhr9FphK+U45rXylegozUZTWv9PFjwb10IFxkh7U7DEAHJEHCXrm0f4jOiwS9rGnIg7HeBa8OTdEJmEZrjFg/PHJ2GRylXhCKBEnNdENbCbEi658/VnNx5SAznYgghWdjFAXLG1wYnk4FKSLZGJedyQgAJcttt6xZx3Ssd7PWYWyWWmm5+FPDq0Keq2mdBbyRHTZzyRWqTmpdYEQV+3bWWb84nx2ouFifcIG34mAGQRtJEklMtMWSgB+FmPZgb6EOoTzCbw 34u0SKCc v2+1BZLMlwLhMKgH2qscilI5hMzlINZetOtZEfm3AfPwafHavTy6PLFJ4LKbuzJi1E/g70Qau69ZGUHMTZksA/2qwxGKuVjFgiyjSG7SDcP9oCtVh1L6hu/JuEvG+O6Sdc8SU5qzziPv072fa2GMFrXQKbCBI1AWixBWOSvDIwSb/KZq+Gg0GDtHxO9gshf1J0Nr/ 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, Jan 17, 2024 at 02:00:55PM -0500, Jeff Layton wrote: > I'm really not a fan of tunables or different kconfig options, > especially for something niche like this. > > I also question whether this accounting will show up under any real- > world workloads, and whether it was just wrong to revert those patches > back in 2021. > > File locking is an activity where we inherently expect to block. Ideally > we don't if the lock is uncontended of course, but it's always a > possibility. > > The benchmark that prompted the regression basically just tries to > create and release a bunch of file locks as quickly as possible. > Legitimate applications that do a lot of very rapid locking like this > benchmark are basically non-existent. Usually the pattern is: > > acquire lock > do some (relatively slow) I/O > release lock > > In that sort of scenario, is this memcg accounting more than just line > noise? I wonder whether we should just bite the bullet and see whether > there are any real workloads that suffer due to SLAB_ACCOUNT being > enabled on these caches? That's a good point. If the microbenchmark isn't likely to be even remotely realistic, maybe we should just revert the revert until if/when somebody shows a real world impact. Linus, any objections to that? -- Josh