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 B7613C433FE for ; Wed, 30 Nov 2022 07:33:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9F936B0072; Wed, 30 Nov 2022 02:33:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C4FE86B0073; Wed, 30 Nov 2022 02:33:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3ED16B0074; Wed, 30 Nov 2022 02:33:25 -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 A66006B0072 for ; Wed, 30 Nov 2022 02:33:25 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 71D611A0846 for ; Wed, 30 Nov 2022 07:33:25 +0000 (UTC) X-FDA: 80189293170.15.45CD0FF Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by imf09.hostedemail.com (Postfix) with ESMTP id 159FA140009 for ; Wed, 30 Nov 2022 07:33:24 +0000 (UTC) Received: by mail-ot1-f42.google.com with SMTP id p8-20020a056830130800b0066bb73cf3bcso10675743otq.11 for ; Tue, 29 Nov 2022 23:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=5AgzOj8U3caSyuY1WKQWxWsXylIKB3XS8A98MNnMeTI=; b=lq99lhtWYhivFicKBQg0Prv5DJ+v/2lt7NSJFbq3rAUCzXgv+KNkTw/xhiyUZyKfqu uMf2C6OYW5swfdUEuSNfmToqqQCvapyvBEvoLa9I53Ndv6qYYJWQY1NpXdK/DMep/mGR 7L8Hl0Jzaihv1Ny3msUYGt7QI5CzigbfwEtDso150EN9K4k5WTZ9i+5r39ViwHjdPomi 1qHBXQNIab2fmYZH+82qfFqdeSinNLbxsAAnnMs/3YJ53sHZ4wwReZDqH1eYS1Phyuy+ zs+pAc+bZtQT8h0FP0tZDi452jQmcPX/LjIw/UdtMpkH4O4GqO+i6KRtz8XtJ1Ob46e0 h35w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5AgzOj8U3caSyuY1WKQWxWsXylIKB3XS8A98MNnMeTI=; b=jdexyuYKrQ/OsTsg8tUoZe/wYnHmJLdTZZq6GXlnibjGMMxtuFp9jsDiPkLBvCYHkV aF4Fi078HVHB3QugWsXPRdARI8Gi/89FW+WGGZUvVEsLUzkaf/4zmwQ4RVsZPStaa3pB WHFwydyXV29yhY3C8gu88L+ik6dDnxAQmaDdYLBWIKvT5s4DkT6LOuZA4ydWD1kUPbow fRq8CjStZb/VFs+ZVEDzTnuW8858pLz05B97O9Hk/HNUfQ0kKvac9UIN5rNpCyGkFWHQ iUQzxJaBZq9DDESuQpIcMR7VejOMd1fTVH7zZmYNPqRGw00r4NHnSxMJo7FEsIYIPxaW 2Vlg== X-Gm-Message-State: ANoB5pkZBrhFZ6ikKKdRUzJ60wf4FRBc3T9iNueq7YttkkkU4Y3fdmHp arqwxqq9HA1ivy1mOeTzY1Vluw== X-Google-Smtp-Source: AA0mqf7Ar78OhaEBLN7YckBESZzpsqFWLuBSeZKsK4PXb8O5CbfqMvcL19+oWPd9nNge0Q37MA+YaQ== X-Received: by 2002:a9d:6294:0:b0:66c:5ad5:325e with SMTP id x20-20020a9d6294000000b0066c5ad5325emr21143324otk.116.1669793604101; Tue, 29 Nov 2022 23:33:24 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id m1-20020a4ae3c1000000b004a002884426sm451137oov.18.2022.11.29.23.33.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 23:33:23 -0800 (PST) Date: Tue, 29 Nov 2022 23:33:14 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Johannes Weiner cc: Hugh Dickins , Andrew Morton , Linus Torvalds , Shakeel Butt , Michal Hocko , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: remove lock_page_memcg() from rmap In-Reply-To: Message-ID: <3659bbe0-ccf2-7feb-5465-b287593aa421@google.com> References: <20221123181838.1373440-1-hannes@cmpxchg.org> <16dd09c-bb6c-6058-2b3-7559b5aefe9@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669793605; a=rsa-sha256; cv=none; b=Pyw9pGxpiUvEncw2nMvCOlD/Sa2YxWf6uU0FjuOAKDjpR7YltIhpGr1YAdAJU5y6kuvOuv TqOAwnp/f5EBVkoUy0OuGHhZCXx7wi6wgeBN7wCrxLRV66eaYBGkCie111pMm1wxA3iuEd zsiFVN9sjQ20q39nglNJcY7pUq7n6MI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lq99lhtW; spf=pass (imf09.hostedemail.com: domain of hughd@google.com designates 209.85.210.42 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669793605; 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=5AgzOj8U3caSyuY1WKQWxWsXylIKB3XS8A98MNnMeTI=; b=fjkSU44zvU2WdXtr+q5N47Hb+VbznLN0zp0NjISWBhM0gckZMmx0Z9wT5HU/IaghLAeJD+ dKU6ldY5gERlb3xClI4+T+afDosUvpa9h4jk8C0NfEMloadbtPFCm8+iUi1V7t5J6fV0x0 rrGolsv/hxuJKrzu2fyWtNb+XxdKxGc= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 159FA140009 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lq99lhtW; spf=pass (imf09.hostedemail.com: domain of hughd@google.com designates 209.85.210.42 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: p3z5n8fyeraap41q3yqetndriuwprpud X-HE-Tag: 1669793604-211139 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, 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.) Hugh