From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Weiner Subject: Re: [PATCH] mm: remove lock_page_memcg() from rmap Date: Tue, 29 Nov 2022 14:08:34 -0500 Message-ID: References: <20221123181838.1373440-1-hannes@cmpxchg.org> <16dd09c-bb6c-6058-2b3-7559b5aefe9@google.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=QmXXccF6gcyyJcn8xYpOax7l00RlE3WtMYxosINrpmo=; b=1kG96GwDm4z4tl5X58tMTSiaw3DnpfdCF/rv7UlXbsY8+W8PnZuGywUo6KHIprE3/m C3/GaQpilxnGQceURvNXTO1ziGUJq4Vc2aq7zP10STkI1U+qpHo7fv8DPSjq5nmE6ZDr C650xqNqffQvPC+Elo1PQXQrtus8NaS/ki4zN58D+ZaxSNRC+Vtxehlx8iQIVmXaEnyn dXr1dJoOKIVqUhDcSoGHaKX3y65ZqZegji+EglMCsAv+k1m5HXwK3Hflzhq4HrxtID2A PruXnlCS3Ni2PLeN/PPbY1Pqv87aHsLGz+Av6nyMfMl+F8m8jTAKXsXDZ+jBt1Cs+Aaf UU7g== Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hugh Dickins Cc: Andrew Morton , Linus Torvalds , Shakeel Butt , Michal Hocko , Stephen Rothwell , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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? 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 36C00C433FE for ; Tue, 29 Nov 2022 19:08:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC7DB6B0071; Tue, 29 Nov 2022 14:08:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C77206B0072; Tue, 29 Nov 2022 14:08:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3FBC6B0073; Tue, 29 Nov 2022 14:08:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A42AA6B0071 for ; Tue, 29 Nov 2022 14:08:38 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 499011606C4 for ; Tue, 29 Nov 2022 19:08:38 +0000 (UTC) X-FDA: 80187416316.03.45B374B Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) by imf20.hostedemail.com (Postfix) with ESMTP id DDDDB1C000F for ; Tue, 29 Nov 2022 19:08:36 +0000 (UTC) Received: by mail-qv1-f41.google.com with SMTP id e18so9039929qvs.1 for ; Tue, 29 Nov 2022 11:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=QmXXccF6gcyyJcn8xYpOax7l00RlE3WtMYxosINrpmo=; b=1kG96GwDm4z4tl5X58tMTSiaw3DnpfdCF/rv7UlXbsY8+W8PnZuGywUo6KHIprE3/m C3/GaQpilxnGQceURvNXTO1ziGUJq4Vc2aq7zP10STkI1U+qpHo7fv8DPSjq5nmE6ZDr C650xqNqffQvPC+Elo1PQXQrtus8NaS/ki4zN58D+ZaxSNRC+Vtxehlx8iQIVmXaEnyn dXr1dJoOKIVqUhDcSoGHaKX3y65ZqZegji+EglMCsAv+k1m5HXwK3Hflzhq4HrxtID2A PruXnlCS3Ni2PLeN/PPbY1Pqv87aHsLGz+Av6nyMfMl+F8m8jTAKXsXDZ+jBt1Cs+Aaf UU7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QmXXccF6gcyyJcn8xYpOax7l00RlE3WtMYxosINrpmo=; b=Wq8m0AcAFwxuGljTmEC2EMEkxtCKdbloiN4KT6w5oogN4GjkXNftyxfd41gBKEMi5R kTDZnhZXRVVPc44MKUB3HAu3bICkA8q3/ORYUACv0yxtzC4bKkMU0iIkv9mKjkkUS87v nASjWPpMcZXZ2SiXa3ZkYQhxbtHRWAYEhk3UUpz+9oDyKBGB1+a/iyLqC+e51RxFmVem RVcj+urOgY9hCfZBI1wLqCLAgQBobBcSHMcbZXemVa1K0s8cSDa9Xvuaw1Oq24aCwR0m tQ+UEubDRyYI4xlaP6IX9kpVaUnGGjcPa/bc8/zWKYDnJyECkCmWj4THDuqbt2/8GXEN IPIQ== X-Gm-Message-State: ANoB5pm/rlTzWdbb2agEx/tIwv3rltaId9WF6GjjqHL9uIIPg3gPyb+o ARnV3UEMc9S7lLIrQ13UgMpoMQ== X-Google-Smtp-Source: AA0mqf7kOv2D0QHrH528Onq6INt8AdhEMV1yVr/SaOZ92ayirYrrlPL0UhZs4UZIEVoDmDOXy1GqwA== X-Received: by 2002:a05:6214:3612:b0:4c6:e2b4:8c6c with SMTP id nv18-20020a056214361200b004c6e2b48c6cmr22819440qvb.13.1669748915997; Tue, 29 Nov 2022 11:08:35 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:ea9a]) by smtp.gmail.com with ESMTPSA id w23-20020ae9e517000000b006f9f3c0c63csm10841129qkf.32.2022.11.29.11.08.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 11:08:35 -0800 (PST) Date: Tue, 29 Nov 2022 14:08:34 -0500 From: Johannes Weiner To: Hugh Dickins Cc: Andrew Morton , Linus Torvalds , Shakeel Butt , Michal Hocko , Stephen Rothwell , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: remove lock_page_memcg() from rmap Message-ID: 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 Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669748917; a=rsa-sha256; cv=none; b=digk3IS1FzmEDPkhZ/FPMShgBYZvjt0GLv684WbfCchmaXnrGhjgVMSxgEP5lytf7OVYDs WgPJD5yfHey+S8vJAyQbig/F587yNqH4QUZMTgY+9589PLJZYw0wzhW/LqRYqdgDSqI/yF ZQJAUlGhkn2hbElRQ2n+t+Qbidz56yw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=1kG96GwD; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.41 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669748917; 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=QmXXccF6gcyyJcn8xYpOax7l00RlE3WtMYxosINrpmo=; b=btWXT5CeCsMnecBM0DFJtg8htOcWSUj9Wg0qRPxXKM0CLa2iAoWdcguF7ncUDU/2ddryec YxrV9+JNsZKW4K3z6CYZjViiTN1IZDhfS+diHm/Tyds/FkD44VrSVPAdQZ4F/z4ye6lopo 5OAe5geXaQ16g55a5b3iySMz0kkm+pw= X-Stat-Signature: fonrpytgrmiafy7abz5qbzkppxi79sgq X-Rspamd-Queue-Id: DDDDB1C000F X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=1kG96GwD; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.41 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspamd-Server: rspam05 X-HE-Tag: 1669748916-478206 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 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?