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 17689C47DA2 for ; Wed, 17 Jan 2024 21:02:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A271B6B0080; Wed, 17 Jan 2024 16:02:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D7566B0082; Wed, 17 Jan 2024 16:02:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89F656B0083; Wed, 17 Jan 2024 16:02:35 -0500 (EST) 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 780FA6B0080 for ; Wed, 17 Jan 2024 16:02:35 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1779614064C for ; Wed, 17 Jan 2024 21:02:35 +0000 (UTC) X-FDA: 81690026670.25.AFEE575 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 22ACD80020 for ; Wed, 17 Jan 2024 21:02:32 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YpnDosOd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705525353; 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=nsaUVhsK+enKkBw1KIJtxzFPjcPyIBpdkEzOvagjDdM=; b=cKRcutVtPGAZnVz9B+qHG50HDffYIntHgKkSo8tC8cwn2XR3bT0TDVcD/ji9XmaZD2kR1w sy6ZrDRAJviEHY4Cax7sm7s/lSg55WFU0wFwJm6NaSJfSSbjumF5WCj2tZkYzo8S3KSaPU OP0tpfaHdzjyamWJMRjCeaT/g4lTEEs= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YpnDosOd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705525353; a=rsa-sha256; cv=none; b=dHA/bqD3yyod67ehmj7TPYBr4zpuCW/PHOek2zpmfjhob98k4QIMgcazV8KvUFKzJinrr/ 41zx+W3oXlHfGE7UzpLlfETy2YvCrykOOXVp8+Qdc6uFL/jl8bpwnab/xzeiSDA8owMwKa Q7gzmYp2FihiytHcyvkovZy4b8AWcWk= Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1d47fae33e0so233175ad.0 for ; Wed, 17 Jan 2024 13:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705525352; x=1706130152; 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=nsaUVhsK+enKkBw1KIJtxzFPjcPyIBpdkEzOvagjDdM=; b=YpnDosOdvZ3hP59Qn0juUvTr8D+oolderSDEUKrFUfgv4Kc3EfzGNUthV8lhGvTPO5 kp5C0e2bits6CreTvIpNWjI7eA1wWImLS+uELiDGIxRhVpWirCXYhF0Ef7x3gWHxgQYf nJhLnD2jlaL67N6DBpaWYO7IC29lmw1WQyyhXPUlFCOb3nV0W6CDDInTON//YoMufnvt jaGWfzf6ws86HPz0VQ4tnn1BscprV94JIsBXOd19aQ10L1FuojyRalwdmF/FW8k5N9di SmtghvcR/hQ4TTbR2vvDOFf3hctGe3vtTGEszFF7tPyCK8x18T1sXR8/OdFHBmR59Uwj 3nFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705525352; x=1706130152; 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=nsaUVhsK+enKkBw1KIJtxzFPjcPyIBpdkEzOvagjDdM=; b=PRYEbilXlKRPzVMUra4EjDFASVU/+Affs2x4bgu93GfPHQ9vdookQgm70pEB+sPjmT w73tyOM4XDXQ7or5a/ySoDonl83gGF9+qPz2dSr90dpQRur4c7Ah4nekCWx9zL2f1hPA sDUS+dZ1Uw1JEeR2Hlg1p5yptjQ712n9z0B0jRfH8SbrDkjBAEPRgC13Tc68v6Ezsb3O zzqyEsBm0jWks72cYXUMrqnfd7QxniuR9Ssh7glRoD67tY3D4g72ZE/m4zU30f2RM4C1 Hpvg731/fqxMNUmzjmDHYGb2emICxxGRz5pVBIjsgVjmmyvle63l/CT3LSXfy9WcEfMM SAtg== X-Gm-Message-State: AOJu0Yx5FAoyZMu6kREw6XwwQIVRjAULThxIUgvHSXmJe2/yEcTymjQL R499ExsoQO0PNSW/5dHXccLSrBKLG2b+cTiKDnyzLF6tcTHFBsoz2RccmQgbrBSYTpIs9LEjH6X gqP3KLLvQkawHIj/xcJn8cBc4BUO+Gy184Ejz X-Google-Smtp-Source: AGHT+IGWIZhqLzcx2+bVk3ob7lrZPkCBExq2fGpUqcnbH0YOKIaCLZflhVKVys1PkHM7n5+U05d1eOq+VDzUvlTq/vI= X-Received: by 2002:a17:902:aa98:b0:1d5:b931:911a with SMTP id d24-20020a170902aa9800b001d5b931911amr234007plr.27.1705525351695; Wed, 17 Jan 2024 13:02:31 -0800 (PST) MIME-Version: 1.0 References: <6667b799702e1815bd4e4f7744eddbc0bd042bb7.camel@kernel.org> <20240117193915.urwueineol7p4hg7@treble> In-Reply-To: From: Shakeel Butt Date: Wed, 17 Jan 2024 13:02:19 -0800 Message-ID: Subject: Re: [PATCH RFC 1/4] fs/locks: Fix file lock cache accounting, again To: Linus Torvalds Cc: Josh Poimboeuf , Vlastimil Babka , Jeff Layton , Chuck Lever , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 22ACD80020 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: fqnozpbzgzayugxkufrqbr16o8ye5xnz X-HE-Tag: 1705525352-125378 X-HE-Meta: U2FsdGVkX19mJMY7HmLu0SPEcyiMDaQOqzzuyCiFazdjZetkstS63qOr9sNy6rD3EVtPRENL3WKQQcBgzDQrHuG+JE+8lcgvT+WdBdt5txPQOY5Tlm1TCjphubiB5R4Co69kHOlxsuhTvLfLYfbtq4d4G/mVWWleH5o7CF3sCZSUqgdpUmjNL4OB44YjMfIXiXfsPE1DOXP/afOKLpRZzWH8hfLEnnW6LjTvT4Kkfd+VWmk2vmP7lVwRQtILW5CcyLvUgZCEDedOsEAVAq0NXJBRkfHoqyaDTejhf28FiYKZd4fhpi6tXA+nJXtcv2xeNgjknpHBITzgSZvrDnMsYlpdZEW9Yte54jCk2csqHCp0ulJKQ7QOFauWtn1pKOowtLhO7hU4/oSHGQNM331R7i0tZ2ibd2CRafhEDMyL6ToZjetA5nWu07U4wpZrNhD4crbPfaXg0T5i6fBiUJB84cCzVsOMXuVHAN6XURZbvtiqKM3Wer+aXdoh+2ot2E3LfAUYxoW8BvTeLyVWyOKJiXoqjzRavnVd+Ax9SIKXqmzAzgapnDF74o6+g5J1cDR4537RspW6YrzZEAlWnQuXzzFU5Wil3hba3cl5XoiWFSfO1GsFtiYEFzu+Wit6FjuFq9p9CX+l7a5HHW/r13/T+aNyLHLVfcIw/oo4GEWAZOgJCaz1IK+WssQUrTCne7S6JzltUu9J1iJ9ADdM1B2fQX5PTJKcMPsXytpxooDkJdHTi/13szESSE+rYoIKiAOAMJ1kt7CFEriBNDUUU59YrRolMrYPa4u/KKseWxw5S5ScC9KkCXVhCl1hAb9c7KGo9pLbmyABVNkSkzIhn9Smklkv0kXFrdBpZghokbtt3kYWd+kv8rtUJ13N/p8rVmoZiN+wQGnbt2eYGMfpRVO259MRsLPxMISIroVm6rrGi7q0ZutwuyHUM2tGjIMo96thFbB/WDDdp2o5nd8+eH1 20Zi18Cf Alq4RA4JDVXGBXNBE05TbL6nUkvdTmxDqvrMCn4S7rBU2Wu+huqhLWswDYhz9RmTMY/sA02SY83YKvhCUU+Y37z/3nTlhpVxnl1hl+wXdacqUu1qEazX63StlmkQsh5/DYnsgeOJtjEqPDKGkg/VcZvLtwarQ0DSFL7UHrW3TE3VPpXDcy1JucFC48lhvwE2/YVGmD3IAV439qbCIG3lEqxrcoegFklTsm4/k3aW3tOEHPmD47Wy/bx0CH5L6lFzk2Zkw/LchTYyqtwxW4d48c171JoPx4/xKZwigoIlMzVve/XwpDwpM8PNiHK50eks6XMZgM/2ZBcb5yRX2M7abt1Sq4BfS1VHd3kD8 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 12:21=E2=80=AFPM Linus Torvalds wrote: > > On Wed, 17 Jan 2024 at 11:39, Josh Poimboeuf wrote: > > > > 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/whe= n > > somebody shows a real world impact. > > > > Linus, any objections to that? > > We use SLAB_ACCOUNT for much more common allocations like queued > signals, so I would tend to agree with Jeff that it's probably just > some not very interesting microbenchmark that shows any file locking > effects from SLAB_ALLOC, not any real use. > > That said, those benchmarks do matter. It's very easy to say "not > relevant in the big picture" and then the end result is that > everything is a bit of a pig. > > And the regression was absolutely *ENORMOUS*. We're not talking "a few > percent". We're talking a 33% regression that caused the revert: > > https://lore.kernel.org/lkml/20210907150757.GE17617@xsang-OptiPlex-902= 0/ > > I wish our SLAB_ACCOUNT wasn't such a pig. Rather than account every > single allocation, it would be much nicer to account at a bigger > granularity, possibly by having per-thread counters first before > falling back to the obj_cgroup_charge. Whatever. > > It's kind of stupid to have a benchmark that just allocates and > deallocates a file lock in quick succession spend lots of time > incrementing and decrementing cgroup charges for that repeated > alloc/free. > > However, that problem with SLAB_ACCOUNT is not the fault of file > locking, but more of a slab issue. > > End result: I think we should bring in Vlastimil and whoever else is > doing SLAB_ACCOUNT things, and have them look at that side. > > And then just enable SLAB_ACCOUNT for file locks. But very much look > at silly costs in SLAB_ACCOUNT first, at least for trivial > "alloc/free" patterns.. > > Vlastimil? Who would be the best person to look at that SLAB_ACCOUNT > thing? See commit 3754707bcc3e (Revert "memcg: enable accounting for > file lock caches") for the history here. > Roman last looked into optimizing this code path. I suspect mod_objcg_state() to be more costly than obj_cgroup_charge(). I will try to measure this path and see if I can improve it.