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 83F4FC433FE for ; Wed, 30 Nov 2022 16:42:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21E406B0072; Wed, 30 Nov 2022 11:42:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CE596B0073; Wed, 30 Nov 2022 11:42:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 096946B0074; Wed, 30 Nov 2022 11:42:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EF98D6B0072 for ; Wed, 30 Nov 2022 11:42:36 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C8208401AC for ; Wed, 30 Nov 2022 16:42:36 +0000 (UTC) X-FDA: 80190677112.26.EBA0B48 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf09.hostedemail.com (Postfix) with ESMTP id 6FA7A140018 for ; Wed, 30 Nov 2022 16:42:36 +0000 (UTC) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-3876f88d320so176823397b3.6 for ; Wed, 30 Nov 2022 08:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pjDPR5yR6DIywWszOgQ0UDhPZ4vEbh5Pko8PrUKf3pI=; b=K86j6VMRXYIQSYFV+KA78qEDNE9v5WU4bWnu4FRw2pC332BzaqIyvlaShvQZTviLZD COiqs6oMwW2dklkvQs/yh280WV+N5Q24S0VgBHZCrlfJLl/ncK8ChCEoWqv/eJYepItk w3TFu1AzI/YXHE0e0rGAG38/r1K85Vt9QOPLE9sGdYGtas73TUgIfS1+ZrPxAmTPeBDV avwm8hAtetBSQ0iCfIXlWtRuBAPQGxskP22jpMWnlLE6CT/Oc8cXnN+ArYwiZhRjHECL lvTKpFg9DZpUKswVxXm+tma4r66CsXSqKTzYnah7h3nBdLDzGmYTnDQ1ARpHDJe6op4r O+Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=pjDPR5yR6DIywWszOgQ0UDhPZ4vEbh5Pko8PrUKf3pI=; b=JtchAaaGRA4Uyx0uqSAW+XckoGusThECoF2TlX1sh3jnKaYVmZttVj5wn9Q0I4ROMU nRIvZs+DevngdUUyL4trrPZIhLPzXih309KPbV3OxYjzV7PTSSvuYLkxJK9LdggPVVnF qO2d/u67QkjrsHbwf/8pEa3/DfCVmH5AxljGjb9I+Ym/lUnGv67dnzlz2cRtUJ8cyLjv CzCYeei0xdb5UFqTVc2tlHe5LFnFx/XD+dlTbkkKyUyOjDxv79YFuQqgadfesN+6HAWf SdCfYAZWU7C2uPHaFyLaBl9CLvZv1HvpHrOc5TB8SLSK7Et9SMEX8LDdTPkNGDoXktAD vv0Q== X-Gm-Message-State: ANoB5pkDlwEkK9dx9dUXAiadIyaQf3lSctUUa1sX2ODJ7vBuDkMkpsoA 0nc6LYKhfxnvHcH0u3/Fb8YOFdlrIvVc1ziM4z7LuZCXydSo9w== X-Google-Smtp-Source: AA0mqf4XJlQocRvwHgq5x6G+DiS5HWePV/wtvsYDvhb/t958IEY8PeYMJEWY84wIyKWoBw2EWDiCO1pk1A/sEmqKBdo= X-Received: by 2002:a0d:d80c:0:b0:3ca:b34:9ce1 with SMTP id a12-20020a0dd80c000000b003ca0b349ce1mr13279423ywe.466.1669826555061; Wed, 30 Nov 2022 08:42:35 -0800 (PST) MIME-Version: 1.0 References: <20221123181838.1373440-1-hannes@cmpxchg.org> <16dd09c-bb6c-6058-2b3-7559b5aefe9@google.com> <3659bbe0-ccf2-7feb-5465-b287593aa421@google.com> In-Reply-To: <3659bbe0-ccf2-7feb-5465-b287593aa421@google.com> From: Shakeel Butt Date: Wed, 30 Nov 2022 08:42:24 -0800 Message-ID: Subject: Re: [PATCH] mm: remove lock_page_memcg() from rmap To: Hugh Dickins Cc: Johannes Weiner , Andrew Morton , Linus Torvalds , Michal Hocko , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669826556; a=rsa-sha256; cv=none; b=r68tNdZwtcsDaVXE33HEsRB1GtQ2iHer5+XI/vUpIyGvtyMNFrvkb86OWbbNYU4gkWEgHE QuqzV66lx0ZcAspdX/isqvYmoz86P0M0j3zXQGw6OH5wP2jnxMDXaKAdPKQ3c7HL5HBaad d9Vwl6pQ42sdRZn9GAj+PriXM7uU58M= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=K86j6VMR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of shakeelb@google.com designates 209.85.128.170 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=1669826556; 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=pjDPR5yR6DIywWszOgQ0UDhPZ4vEbh5Pko8PrUKf3pI=; b=OlpiJVgpHvyQvh4AsPVbuc7yjrvMVoLZ629b6bUTGqULaS4w1n3AabG7Yl4661DWZJILIT k3SDvUvxSUw4KYIQsl3KMB0HEN6S1pFl7d3KpBJhTWgyklWsm2ctnpQ6p1hd8XC1AT1Nkx Bsjg42ZNrj3fMIaw7HAM87k6VfUHXK4= X-Stat-Signature: sjg3ty55ghsmkx5wcnqaxgkjw17ychzz X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6FA7A140018 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=K86j6VMR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of shakeelb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspam-User: X-HE-Tag: 1669826556-963174 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: On Tue, Nov 29, 2022 at 11:33 PM Hugh Dickins wrote: > > On Tue, 29 Nov 2022, Johannes Weiner wrote: > > On Mon, Nov 28, 2022 at 11:59:53AM -0500, Johannes Weiner wrote: > > > On Wed, Nov 23, 2022 at 10:03:00PM -0800, Hugh Dickins wrote: > > > The swapcache/pagecache bit was a brainfart. We acquire the folio lock > > > in move_account(), which would lock out concurrent faults. If it's not > > > mapped, I don't see how it could become mapped behind our backs. But > > > we do need to be prepared for it to be unmapped. > > > > Welp, that doesn't protect us from the inverse, where the page is > > mapped elsewhere and the other ptes are going away. So this won't be > > enough, unfortunately. > > > > > > Does that mean that we just have to reinstate the folio_mapped() checks > > > > in mm/memcontrol.c i.e. revert all mm/memcontrol.c changes from the > > > > commit? Or does it invalidate the whole project to remove > > > > lock_page_memcg() from mm/rmap.c? > > > > Short of further restricting the pages that can be moved, I don't see > > how we can get rid of the cgroup locks in rmap after all. :( > > > > We can try limiting move candidates to present ptes. But maybe it's > > indeed time to deprecate the legacy charge moving altogether, and get > > rid of the entire complication. > > > > Hugh, Shakeel, Michal, what do you think? > > I'm certainly not against deprecating it - it's a largish body of odd > code, which poses signficant problems, yet is very seldom used; but I > feel that we'd all like to see it gone from rmap quicker that it can > be fully deprecated out of existence. > > I do wonder if any user would notice, if we quietly removed its > operation on non-present ptes; certainly there *might* be users > relying on that behaviour, but I doubt that many would. > > Alternatively (although I think Linus's objection to it in rmap is on > both aesthetic and performance grounds, and retaining any trace of it > in rmap.c still fails the aesthetic), can there be some static-keying > done, to eliminate (un)lock_page_memcg() overhead for all but those few > who actually indulge in moving memcg charge at immigrate? (But I think > you would have already done that if it were possible.) > My preference would be going with the removal of non-present ptes over static-key in [un]lock_page_memcg(). How about the following steps: 1. Add warning in memory.move_charge_at_immigrate now (6.1/6.2) that this is going away and also backport it to the stable kernels. 2. For 6.2 (or 6.3), remove the non-present pte migration with some additional text in the warning and do the rmap cleanup. 3. After 3 or 4 releases (and hopefully finding no real users), we deprecate this completely. Step 3 can be delayed if there are some users depending on it. However we need to be firm that this is going away irrespective. Shakeel