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 8EA5DC47258 for ; Wed, 17 Jan 2024 20:21:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB64E6B007D; Wed, 17 Jan 2024 15:21:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E663F6B0081; Wed, 17 Jan 2024 15:21:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2E076B0087; Wed, 17 Jan 2024 15:21:23 -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 C282B6B007D for ; Wed, 17 Jan 2024 15:21:23 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7B6EF120778 for ; Wed, 17 Jan 2024 20:21:23 +0000 (UTC) X-FDA: 81689922846.10.61EDA59 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf28.hostedemail.com (Postfix) with ESMTP id 797E6C0014 for ; Wed, 17 Jan 2024 20:21:20 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ObIBg9Yi; dmarc=none; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705522880; 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=VANeRlQcKNuS02RIKSNSaBerKvZvwIN+PjhVd8nh4E4=; b=KwNf0L3Uwmw3wMTF+X/nYTNsxwwyrPRctsUPSC3ZuSEgiLWUNG1IWlv0Tco9vI9vzfXBME xIcd46ODajVitcTGJKm6HbxKqEVPqLeDDJJaqvuSgwM1evPOodx1zdjQa9HpqM3fqzQcD7 zyX1I6NHZ+/LS1undQfnseOC4/CX/hk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ObIBg9Yi; dmarc=none; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705522880; a=rsa-sha256; cv=none; b=xGnky6OzehJ4kGlR570EOE2o6KZBMC/erS9Sdzr3QkfQjTd/bXOMBEyBe8iCrsUHRrACPQ 0grpNvisWxSFrShGzLI9m/xir/2Wa+weM1boQgvimmSskCTiM7vG2n+rwifAfuc+A6wspm 6Tz4J66m1n/ZMYbx6P8zdVemWAlWmZw= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-556c3f0d6c5so14202104a12.2 for ; Wed, 17 Jan 2024 12:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1705522879; x=1706127679; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VANeRlQcKNuS02RIKSNSaBerKvZvwIN+PjhVd8nh4E4=; b=ObIBg9Yi9wLqn6PWCqQRIeNW5ROJXJ4L/qTzQ48ZfW/pEDp7TDzABYqcC0WDm2S/2u k6UBIN5rI/PxtVBPGRrG6tdtHSKl2mY08bPS4xgnxcereKBpCtxT22c9MzaRkf05IxDf Q1PrO6BvSEhkYpyE0MBxuqTOVZOKIpQN4rBrA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705522879; x=1706127679; h=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=VANeRlQcKNuS02RIKSNSaBerKvZvwIN+PjhVd8nh4E4=; b=WfN3aJaTTCWv/qxCZfsy+p5oeOBE3TBnJ3tFA2dAQ/MBQPs64zYEpTIRjPlvrFCVNK J4RRsakbDtJXu8jkO2vqQ26eJCjKoM8PNCcPno+AWhdjYQRl2TWiyc9zTWxbl4hTIZFj rfRHNDz5gmVu+Xg+0YjwpDXxwrJjQUCvhjqzBeI4AEio9gGO85z7euYuE5+PfM8IsavA F8HDqMd3UqkQYj95y0HP9tG+MU6ZoF2frqHuVZ7sSngrodDQYdp4gd0OBG+dFZdP3vUk KauMPU9Vxa9rpFedjJNYABwLKLa+0ZaCP5xrEB5ojieGkWj3042nw9g9K8AS0yddYLxE Vpcw== X-Gm-Message-State: AOJu0Ywb1DI/rZyWw7DOSuYImEJmQ30PNqzibcAHpwhYvawcRd5YF7P7 wcd3okCrDi6hhskQYED26rOG3sp/lg95BIA5xMU1hEzO23uPFjhb X-Google-Smtp-Source: AGHT+IHH4ZaDBIwLZHdKD1Xbq+lvQW9K3ow5YKRYGbiycj40WMImidARAFn5dQCN8lNRA4/aqA1DeA== X-Received: by 2002:a17:906:66ce:b0:a2c:cdef:a673 with SMTP id k14-20020a17090666ce00b00a2ccdefa673mr2795236ejp.99.1705522878884; Wed, 17 Jan 2024 12:21:18 -0800 (PST) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id l11-20020a170906230b00b00a27a32e6502sm8138845eja.117.2024.01.17.12.21.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jan 2024 12:21:18 -0800 (PST) Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-40e7065b7bdso44087435e9.3 for ; Wed, 17 Jan 2024 12:21:18 -0800 (PST) X-Received: by 2002:a05:600c:1552:b0:40d:5502:5834 with SMTP id f18-20020a05600c155200b0040d55025834mr3233229wmg.14.1705522877914; Wed, 17 Jan 2024 12:21:17 -0800 (PST) MIME-Version: 1.0 References: <6667b799702e1815bd4e4f7744eddbc0bd042bb7.camel@kernel.org> <20240117193915.urwueineol7p4hg7@treble> In-Reply-To: <20240117193915.urwueineol7p4hg7@treble> From: Linus Torvalds Date: Wed, 17 Jan 2024 12:20:59 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC 1/4] fs/locks: Fix file lock cache accounting, again To: Josh Poimboeuf , Vlastimil Babka Cc: Jeff Layton , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 797E6C0014 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 9zm7u1g15wshbx1eyp39qztt1ib6wy5i X-HE-Tag: 1705522880-106720 X-HE-Meta: U2FsdGVkX18GZ7VZjbwx3qR6H4/hjICcW4RjIJYE8DrgWQJuW+EZ8p6ZQ8IiFo2Xkdj4FsqU8zhRQSHtuFOyfteOCkhOewUUPhAjXApTMQXvVfUYZUEdsOrxb/popAgdE7KeE5z2pP/tbV0QqqFU14BXS+s8JgenymAoM0w2taRgivIOR63c2+HuuOfIHll66eeDWnDftWfqku+NC5royj69CpJh+iEFdLlzeiW3BRrs3OSplYU4oh3XXFjj2DNvzzeBxpcW61HbRViAvI+tzX6rMAA8CuGWlaXOau00kx850NpERM0nqGR558SuiMkq++Iv9SOBA+KA1HoZ0+dUf254hScnjRY+Snt1JSjsnFHNa3Okgb+BWmubYr1W/My4qBIIrsjg7oCUeIDR6j0PENjwb8lKQHFUTQFOaJPqiJp/kbEKUAk68rtznYrZKDA7wtlqNqKMQBwib3u2GywrGQLiwEen6dzyyGxIWzrff8ZaCr02j+13BIycAaJLn0Gt0OZVeZVPZkyk8MNEcslLg5oa0adyytGObCH0MD9wBaPyFMs0/54qFxzG9qAIsQmiYjFJ8E5iFyHIDgP0OoTywsv268A0VO5zRdind6rr2GQaVbCI6chXju3OxLuJLviBS67LDmXKYJYJvSH8Y+PY+Zn7DNS5pWwyBI/584paY14muetbl4QgSs56gwrv/lHycEQ5TtBiCb5un9WJ7LPor1JG87hz9Zh0gqGbU8aAipWJozkPp4UFK6EsGcM7n2DTrH46GEYzSf8+hhGxvm1r3yjM7g0+fs0Zh9MIYUyGpXRgOFH8OVckykYYddRUu92f+hoCFHDo5RpeEyxEJicIO+tiv/2LACYd8j/C9zVKwrG1TCPz+OXMNtMd0RyTjb+QY6je2PMOfiui47RxiV37fa1ZCfmyd7S+7yOlb6U6ZZRVIaNrvkBaWCy2r+8LWPMHF5yqBTtjwS3qvyt2rr+ ImqBrKHp xXM34LyQsVBUc5mSktfGd8ArwwPbWbbde4hUDtm8wA06k5XwekvuBZuSfV2G+DXuHZFdowwvp0ZbbGLIIA9HuoU2BRRaPfiduJimhBcqSZIYh6KTIaMNJHXqvlYR2P2kUkYwrbfdgMRgKHMfA4d3Cp+lnsGrMe8BlzWCnAC3C0+nq8Qux0JrpAoptj8kFZSN0+RHwkjlk08zZIe0Y76gaLPo+ST3MN3Kinv9p9sa/XjUk2PqrooiGBH5x67mZLpn4tr+349JD1n78Y/FLP6vLxK0mvqxXASSNVhdFUOn4hZtsTaaoSoDwgAQpPjv73NJ107qROqi4aukjWocpr6hMxRrwa1Deb2NbDL+mZxtXabgQHWiRZQSCwyRHWNsOYhrWyef/UO6cbpMl6+AUcW3p9CQ0BUFu+idYmBtjE/JCTniWAMZ1uKOMrWXNHqXgcGAL2nQNllysnab33HoGazBiDyDyyT9rXyZNT9TXHWQXomVRnI/xUsyfFCHMqMoBLQxvEllqYDrbh5mjQ7ZhuLeAGQs/t7+cFIgrjes7pUjAs+Db+BDGONijc40GXhoSdEplahPIU0bcZpw9FzLtaYUDzT7seAIO2zOqn84Fw46jSZbpR+Zw5bU3tV6JHQ== 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, 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/when > 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-9020/ 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. Linus