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 46ED3C4332F for ; Tue, 22 Nov 2022 06:55:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0BE86B0074; Tue, 22 Nov 2022 01:55:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB86E6B0075; Tue, 22 Nov 2022 01:55:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A805D8E0001; Tue, 22 Nov 2022 01:55:18 -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 950C26B0074 for ; Tue, 22 Nov 2022 01:55:18 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6AA8BC09A3 for ; Tue, 22 Nov 2022 06:55:18 +0000 (UTC) X-FDA: 80160166716.14.33332D7 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf01.hostedemail.com (Postfix) with ESMTP id 389AA4000A for ; Tue, 22 Nov 2022 06:55:14 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id a27so8726306qtw.10 for ; Mon, 21 Nov 2022 22:55:14 -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=mYAqDDk/54FmeYnzSCfE4ubLGzPeGRlE3OkG0R3fi1g=; b=0RLPsjsq8XFYFsbBP31qFJbsIjbs3BM99Hd75XBgqLbKxUqoZYlpPLWpIu4K7iAZsv KDQoslmgNXaijNZMlDhzaIxhg47IL8/8frC1xBQcmS2HqfZH/6IaGb43LzLTqw0U8OoH tlFJX/1st+DaU+CjYO3toBQqOhCyPMaYaI5dXW00F76nvY2xK4jIhi4AjA4EhPVnBIwY 6RorVI7v7SFsbixEWrgw7ilExM8XtSYriWyNCAlCdPrvWXVNadIoKpTqi+mGhP1qGPen AL1uX7jTAc2Hd2OGYxYua2oCEhkSy+bPWR8kLdIrt/yhJp1pW/PX1my5Ob+oJbw2gr6x QWjA== 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=mYAqDDk/54FmeYnzSCfE4ubLGzPeGRlE3OkG0R3fi1g=; b=35szuRb35zO0uK1JfjS6Ceyo/uAknzdHU2oCQwplkb4phEjrKaSBncaQQNGTOcVUAo GRkjeFBetEd4BVRltOsT8ERajj9wG2DiIbVzw6TpVBC+5TYymuupeeal/quekpY7QZxC Tsbwllwe/kA9/WfKxONe/Qn3y9uKhOUGXEBeGZwg+Zk0IvL5WBB/JsYnWeA7I1zg6M7E S781jJG4js4eX5hIUzACxaLWaLncK3/ppXFeO0Dyy25ekEeuz+jUX+oxq/x5M18ZkWb3 KNYpdV+qyJegyeoQFYet+F+rfQYa+jHVwGP7Mt26nYFNNIbRoHnx14UOb6qdjpgscExL wAoQ== X-Gm-Message-State: ANoB5pkqnlbfeZ3zQgsB7h3ggW99uahypRTtJKNPxWG9S3Ohhm+UAcsj 28/J642rfo8PCc75aEJrZ0qZwQ== X-Google-Smtp-Source: AA0mqf4P6pkD5sHhG+0KqzdmxYPTWy5bEJgBXaYTAAGJzSjBw9ZV52sjvx8xr6k9OKWhuzqNzcWbAw== X-Received: by 2002:a05:622a:5a96:b0:3a6:3b3a:e8cc with SMTP id fz22-20020a05622a5a9600b003a63b3ae8ccmr11975315qtb.373.1669100114196; Mon, 21 Nov 2022 22:55:14 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:bc4]) by smtp.gmail.com with ESMTPSA id bl9-20020a05622a244900b0038b684a1642sm7888922qtb.32.2022.11.21.22.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 22:55:13 -0800 (PST) Date: Tue, 22 Nov 2022 01:55:39 -0500 From: Johannes Weiner To: Matthew Wilcox Cc: Shakeel Butt , Hugh Dickins , Andrew Morton , Linus Torvalds , "Kirill A. Shutemov" , David Hildenbrand , Vlastimil Babka , Peter Xu , Yang Shi , John Hubbard , Mike Kravetz , Sidhartha Kumar , Muchun Song , Miaohe Lin , Naoya Horiguchi , Mina Almasry , James Houghton , Zach O'Keefe , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 0/3] mm,thp,rmap: rework the use of subpages_mapcount Message-ID: References: <5f52de70-975-e94f-f141-543765736181@google.com> <20221121165938.oid3pemsfkaeq3ws@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=0RLPsjsq; spf=pass (imf01.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.173 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669100116; a=rsa-sha256; cv=none; b=lOE24obZvGEJpb6u9IqXqkH8rtTIqHIm4+Zpxzg0EJ5HLtLrrgFiwtCXYAMpZHld3pqDpk 6PPaCC3L3fmFgwgDycnZpaiFbTe1BwWkZ2jK/WkUhQpYiRiQajhIqXPFNpR6TtvZbJNUr6 nN1ZkhIjSX3tvoCKmRGqPl/j+S+sXOs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669100116; 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=mYAqDDk/54FmeYnzSCfE4ubLGzPeGRlE3OkG0R3fi1g=; b=IaMCY77ej63v/URWhNUecaIcgjsIGah96gJpqKlyirdvOz25JyA8BqLZIfkI/bqyfv2DPz 1eTSgrdFWbmR37nyUNpxanUHUM7lIYryfR47z8XbBcJH5G43cTEaiLTq7m+Vw9oafoVLBY TevvDtLMzL8XQlpuHR5Co0eHEA+4eZg= X-Stat-Signature: fp8n79wtfazfmtda1cajio378soyxm94 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 389AA4000A Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=0RLPsjsq; spf=pass (imf01.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.173 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspam-User: X-HE-Tag: 1669100114-902520 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 22, 2022 at 05:57:42AM +0000, Matthew Wilcox wrote: > On Mon, Nov 21, 2022 at 01:52:23PM -0500, Johannes Weiner wrote: > > That leaves clearing writeback. This can't hold the page lock due to > > the atomic context, so currently we need to take lock_page_memcg() as > > the lock of last resort. > > > > I wonder if we can have cgroup take the xalock instead: writeback > > ending on file pages always acquires the xarray lock. Swap writeback > > currently doesn't, but we could make it so (swap_address_space). > > > > The only thing that gives me pause is the !mapping check in > > __folio_end_writeback. File and swapcache pages usually have mappings, > > and truncation waits for writeback to finish before axing > > page->mapping. So AFAICS this can only happen if we call end_writeback > > on something that isn't under writeback - in which case the test_clear > > will fail and we don't update the stats anyway. But I want to be sure. > > > > Does anybody know from the top of their heads if a page under > > writeback could be without a mapping in some weird cornercase? > > I can't think of such a corner case. We should always wait for > writeback to finish before removing the page from the page cache; > the writeback bit used to be (and kind of still is) an implicit > reference to the page, which means that we can't remove the page > cache's reference to the page without waiting for writeback. Great, thanks! > > If we could ensure that the NR_WRITEBACK decs are always protected by > > the xalock, we could grab it from mem_cgroup_move_account(), and then > > kill lock_page_memcg() altogether. > > I'm not thrilled by this idea, but I'm not going to veto it. Ok, I'm also happy to drop this one. Certainly, the rmap one is the lowest-hanging fruit. I have the patch rebased against Hugh's series in mm-unstable; I'll wait for that to settle down, and then send an updated version to Andrew.