Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4592172rwb; Mon, 21 Nov 2022 09:22:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf67cGsBNeIuRv4M3EMLs7LeGNRKcvF1quZElxieSx8pjPfx9LCfAtyvwXMsRivclClrFqw9 X-Received: by 2002:a05:6a00:1303:b0:561:7dc7:510b with SMTP id j3-20020a056a00130300b005617dc7510bmr21388671pfu.3.1669051363676; Mon, 21 Nov 2022 09:22:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669051363; cv=none; d=google.com; s=arc-20160816; b=pZfE8N59Hsghd0z4P/tJjU61H6tzPmy97aXDEjppJHUDOGd9DzpPRpkDFvjMoHAoXZ EQ6dlDH8jJJp91kaU5z8+e9QWGVbq+p6szH8luu9Mw8kvuCpdzkyzbaMUoMkfGwqhqL7 QxJQbzj9IuZ5XGUW3etVLpDlyDvyPlEdY0SFxSLO1zLBDk7Kk0LEaH6PN1i8QaOVd4N8 c0Mo8izMg90xD7QjrP7ObVPIwmsmjwCV+qKw5PhiHNVd9xRBEPql02EMDscg6TX6nG5E pIl/6rTIBqaKHMij1p7/y2Iibi/h4V/ipH4phHjIXNnJIuxYAxJS6+uBGbEruiNbmtvF HHrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=d1E4/GFb9ka3QG/dqe1GLOVhL1X2renMDEhnGD/6nC4=; b=SopFY6Em31aSE9nLzpDSCOhgXJBPBTFIr5sWZCEBridwQfm/j9ebMeXRhUXZzFsh5E wT2jFhO6RbCFoDHRTcqn1bWb9eslGnOVFsIcz5hc4Q1MwePcck5sG8++YIn9dQFvQenw qDkYhrbXGm2im4NhaChIUNnuY1Ucy2Uv7Bz+zHOkRpkS0mx01GOCx1gm+47nekIZHoNQ 1CjoZytyzFIDvCXjIeMcE5ek3E8/WtwbngQOrarxfCgY5hk0RZcxC8jCgExj5bTuFJ1S ThZPv15z35EKo8fLEoAlD0XhcFNLZvYidnHGFfO5Ic25+98iaOQi5su5Y/p8kGCZgIJI X9Yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=icI3QdnV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 20-20020a630d54000000b0047697539353si12147461pgn.656.2022.11.21.09.22.31; Mon, 21 Nov 2022 09:22:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=icI3QdnV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229647AbiKUQ7s (ORCPT + 92 others); Mon, 21 Nov 2022 11:59:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229909AbiKUQ7n (ORCPT ); Mon, 21 Nov 2022 11:59:43 -0500 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A7E2C8454 for ; Mon, 21 Nov 2022 08:59:41 -0800 (PST) Received: by mail-pl1-x649.google.com with SMTP id n16-20020a170902d2d000b00189082beeb4so6221598plc.16 for ; Mon, 21 Nov 2022 08:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=d1E4/GFb9ka3QG/dqe1GLOVhL1X2renMDEhnGD/6nC4=; b=icI3QdnVXbEM9Zb9gKG4OS8A102V11jOmTdeKnZkJFoahQg4uNVCTchDDCo2oKkBsD SNLhbWrGSgPB1+eK5ksS7hZeeGnEKC+c+5Xgy6232GUS/DlRfEXQYJ8+Zwf7cyEPCsBs KvUZ1zJCSL9G+UpqjOdi2JF5vLC2iuoCyhVOBqzekSGezGiRa+yGSG9BbNZK7pjizDg2 zxhAp2Bo4znrkfnREeAaONnXRoOe6Pi05x5MJD7Sb262M533o2UBrURGmT8Gx8SCpEqa 25XAivGsGrnR1gLaYZglogvdS7b5HyNFHIZ6c4+ZPW42m/ArG3ZSE/kfOFu4Hkh/tIZO rKjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d1E4/GFb9ka3QG/dqe1GLOVhL1X2renMDEhnGD/6nC4=; b=N+QbJ+K39c9gCP/aUxmUbyk8DuP0KXT9TdaMo2m/RZkqGKpANxzZYy8v4aMB6F2t8s ibyJNCspH3+eZVuMZcrvEJXS7Z78BDe1sZwacIbBvYw9vVoo6UNQ6T13oTMVOV/bJEgM coyxMMkn/0+fwDNacWrbA8lVbr1VCSJbcnNYjhSUX+R/d9+dLITbCS30SOt4VicPoAA4 s6CMPl6fQ0XKcgAqZXyYgNRcpvW0aP5Bupr35gaaUEMC9yN+bXa/boGOM37FENs5RtAC ftYYqoegY0hsiwFb3sIqdGJKLn1ytdRkoHLiAtzWwL/E0ffyHHLH5OtFvycwqzif/G0O r3qw== X-Gm-Message-State: ANoB5pmGuHczBaLAiBCUT1vHwJ3xm6yntJaeH+rFIy+q4fKS2Nyql0V7 OmvepCrephJBqvMLjLZ0ZbUwNAeXrqvPDw== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a05:6a00:330e:b0:56c:d93a:ac5f with SMTP id cq14-20020a056a00330e00b0056cd93aac5fmr3712874pfb.48.1669049980947; Mon, 21 Nov 2022 08:59:40 -0800 (PST) Date: Mon, 21 Nov 2022 16:59:38 +0000 In-Reply-To: Mime-Version: 1.0 References: <5f52de70-975-e94f-f141-543765736181@google.com> Message-ID: <20221121165938.oid3pemsfkaeq3ws@google.com> Subject: Re: [PATCH 0/3] mm,thp,rmap: rework the use of subpages_mapcount From: Shakeel Butt To: Hugh Dickins Cc: Andrew Morton , Linus Torvalds , Johannes Weiner , "Kirill A. Shutemov" , Matthew Wilcox , 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 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18, 2022 at 01:08:13AM -0800, Hugh Dickins wrote: > Linus was underwhelmed by the earlier compound mapcounts series: > this series builds on top of it (as in next-20221117) to follow > up on his suggestions - except rmap.c still using lock_page_memcg(), > since I hesitate to steal the pleasure of deletion from Johannes. > Is there a plan to remove lock_page_memcg() altogether which I missed? I am planning to make lock_page_memcg() a nop for cgroup-v2 (as it shows up in the perf profile on exit path) but if we are removing it then I should just wait.