Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp645258pxj; Fri, 28 May 2021 12:00:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOsXf3Xrhv5BhwR0Js5Tsva93OSWuBeO6uuzb+t3+8P/b/xCOPFb49SnLU1/xKQixn5ErC X-Received: by 2002:a05:6602:189:: with SMTP id m9mr8136714ioo.88.1622228411370; Fri, 28 May 2021 12:00:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622228411; cv=none; d=google.com; s=arc-20160816; b=bFrohT6xAikwoZndwK6WCUMi97WoaS9J9JMIshk8LNx8kK4RBtpdKKvoN5uI2ePWHl PmzrYBMUg2grqKJeWiv96v1JzSV+womMbyu9ia8W5rQDct1iDOfMkK0JvB81Crj5l9fE 9ehbMdfMpQnxQdvoWEMhNcihD2oxqZ1j4+5AlaQnQo66eQhbx9ZXAm3oddFjOVQ3JjYF H+YitlalDvguaRLfDs49I0GmK4dGZSnxiOnlbwdZs6OuzEjfJDxUxOOcxYqih/9zk35d x0w1hr0Pt83l4zlyh5WmyWe+UicH+7OuCFfpQmmKPzmvEzQN80+xCLuRvl+K8U3x8H/5 +A8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=kVbbn9Tllju3ajh8WBDFibkdk2WLCqQZwjz4DxeixVg=; b=LtA+nGh1Fib7Y16UZ2NpTXJWrRpX8zX/h5yS2nei0pn+EHLnkrkiLNHELGltiLUH3N 63KAaFC3w92xwYWcaWSzSa7dwUtmsQacHmnwLtm7PS4Pxz8yejfFxRmE9JwqqrySoH0i LGNbDG34SpP36CjZsQUuGrkhYfFixbCpuneTK5/NbjUtv+IKPSV+HViRdyZv1hh9xiW1 EeU8FlXKcWbQw7/PMy+SF0SLk176ZQNt7tedCmCa4tTx+HwXS3ARkbiu1BcCgO9apNlm DoBcoVJfDi1Kj2Vqlj7H/1W2AkyZE7rX/nYSChg2gCydD4ENjGz1KaeHtE2FGgruiy2Q o3ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o8MAWiiP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d8si6075516ilo.3.2021.05.28.11.59.56; Fri, 28 May 2021 12:00:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o8MAWiiP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229520AbhE1S6s (ORCPT + 99 others); Fri, 28 May 2021 14:58:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbhE1S6s (ORCPT ); Fri, 28 May 2021 14:58:48 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1864C061574 for ; Fri, 28 May 2021 11:57:11 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id gb17so6808721ejc.8 for ; Fri, 28 May 2021 11:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kVbbn9Tllju3ajh8WBDFibkdk2WLCqQZwjz4DxeixVg=; b=o8MAWiiP+EedC79OfXmHH++BL0hoE4dXtHp72RwzksF3nBUatbYbHyZW9+Y6vfu1XF ogG7yxFsG7Lq64QEFHUot8HXaLKln7z13Vp8yI8pvsm1FnxSDkWIvej4VXkbb+2mzMLY lkXs98fhm8PIe10qY7zx/aKHBdn+LUxgEra9/oDEpMYIsIBE2mnt1Wc6NutHJuPDTUv2 XQF1QFGkEJsA+qyzv7aporio0YCQP7sNREElMjnWhHaAKeNfIBciBklxpaMybEe0sHNp Mn191Xm3XXRW2UU3Y+tjjg5VjLl6MVPoXZmB4JKBzy7e/myhVyyQCdfparN7YyZg/oZD S2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kVbbn9Tllju3ajh8WBDFibkdk2WLCqQZwjz4DxeixVg=; b=AoMWxoGfM3t3AD43RkYp2XrPoyG1BrYou9ziGlAB8j7b/WOgJPa5Yt3yRA+7b9XgiC ZJuXOrFXuxBntTi/A4fxiau50ZdkWdWiT777wSU4GEx0oJRhUwIpYScppV/eleAas0Ro eVoZHA06jw8lAgS0cyVfYuHh6vAcdR+vFRkwRm5k0mH6JtMnkKRwAtq6TZJhCUOkfjHL uaI56dnb+SUtBq53pIhlgp3y5pDcSYSWR3pMcbdbwlXmFIksxaGPJOpXJvxO0vtjRu2j y94HENJ/ccc2qk7Vc8kH3mSySp9BH3H+97T9bjTzwZUAaOngHhcfBG0fXMqwPN0Ia7En 2GVg== X-Gm-Message-State: AOAM532wcLqGMeMQO48lOSVAcyE3gsfiwNkm6et3T+y+6fkMGAFXUIPY j2ouByBMcc/CdWLkw4zwPSt/FcgJC8fW5UOLDOQ= X-Received: by 2002:a17:906:da1b:: with SMTP id fi27mr10497141ejb.161.1622228230486; Fri, 28 May 2021 11:57:10 -0700 (PDT) MIME-Version: 1.0 References: <20210528175403.4506-1-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Fri, 28 May 2021 11:56:59 -0700 Message-ID: Subject: Re: [RFC PATCH] mm: dump_page: print total mapcount for compound page To: Matthew Wilcox Cc: Hugh Dickins , John Hubbard , "Kirill A. Shutemov" , Vlastimil Babka , Andrew Morton , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 28, 2021 at 11:22 AM Matthew Wilcox wrote: > > On Fri, May 28, 2021 at 10:54:03AM -0700, Yang Shi wrote: > > So I prepared this patch to show a possible approach to get some > > feedback. The same thing could be decoded by the reader of page dump > > as well by using the same formula used by this patch. However it sounds > > more convenient to have kernel do the math. > > You haven't taken enough things into consideration ... > > > + bool is_slab = PageSlab(head); > > We should probably have a separate dump_slab_page(). Almost nothing > in __dump_page() is really useful for slab pages (eg, mapping, index, > mapcount, compound_mapcount, compound_pincount, aops), and the flags > (such as are used) have different meanings. Yes, slab page dump is missed for a long time. > > > + nr = compound_nr(head); > > + if (is_slab) > > + total_mapcount = 0; > > + else if (PageHuge(head)) > > + total_mapcount = comp_mapcnt; > > + else { > > + if (mapping) { > > + if (!PageAnon(head)) > > + nr = nr * (comp_mapcnt + 1) - comp_mapcnt; > > + } else > > + nr = 0; > > + total_mapcount = refcount - pincount - nr; > > I see what you're trying to do here, but there are so many other things > which take a refcount on a page. The LRU, the page cache, private fs > data, random temporary "gets" (eg, buffered reads, buffered writes, > get_user_pages(), readahead, truncate, migration). I think this is > likely to be so inaccurate as to be confusing. Yes, it is inaccurate in some cases. There is not a simple way to rule out those random transient references. The page cache has been taken into account by this patch, but I overlooked private page and LRU cache cases, they seem simple to filter out by page flags. > > I had to think hard about it though. I like what you're trying to do, > I just don't think it works ;-( The random transient references are annoying and could make the number be far away from accuracy. That would be too confusing to be worth printing the number. But I'm not sure how often or bad it could be.