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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13033C001E0 for ; Thu, 27 Jul 2023 13:16:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232561AbjG0NQn (ORCPT ); Thu, 27 Jul 2023 09:16:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231922AbjG0NQl (ORCPT ); Thu, 27 Jul 2023 09:16:41 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF8FD2738 for ; Thu, 27 Jul 2023 06:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690463741; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hkGX/h7m3QPOunZGgc4OMZF0dALyUJfLw/fdSlyp7rI=; b=IfuYyHu1eX0odvkKr5Oie4JLNTKC5rSsfr2twm2edtwBO30isL0ITEChS8QKonZl/o1C5q nUpG+qkY+wx31O5oQwzAfL7lLNRXW+blXXTtFfJ11oB0fffJBvB+tj6LHI4EpVsquMSe2X j40ZpOly6RUPVJ2shXzY6WefTwuqjd0= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-30-CAK5pqRIN2ybccFUop1yzA-1; Thu, 27 Jul 2023 09:15:40 -0400 X-MC-Unique: CAK5pqRIN2ybccFUop1yzA-1 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-767edbf73cbso20940785a.1 for ; Thu, 27 Jul 2023 06:15:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690463739; x=1691068539; h=in-reply-to:content-transfer-encoding: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=hkGX/h7m3QPOunZGgc4OMZF0dALyUJfLw/fdSlyp7rI=; b=e8AOLrP8uY/npD7yUl3M/VRtNEz6gi8qhyWzuJhjsW+3bAL/EdSDnIsNrvnFiQUclv QegUpa58fJEAHihSBJEWMV4SWfEijmmfzARyhFp+xOTaBZd7JcTOFj5/MDIPhiG+FZtU iK1CrfJOx70/fnB+IpTjlkVR9UP6f+et+d7nE1u2ZRzoCoiBMhAK54+FjnqI7U+H1eLV rbYfVLVAlP2VVoKsRxm+65gVGXX2m5P/GWCDxnZqRCL0RTwIblESdy+cD/EKaJCYmwIu QfXKBi7NlWbHO2oNWFboSGgRlss2ndqfS2fVjnTQ91GTq0vbIoFXRbtDGJpRwIh1BTip cp9Q== X-Gm-Message-State: ABy/qLZo5JdDK2gFd8Kdbu3XGvUEHTuUXsGVhj3+Uq6hRSlFbsLXIVY5 7XwsYtYL5XwTh5hzjDYu7VzkMWtw3W/Ikd8nxeWFQITP6iyGiXTgvAAEVY4/MaMQsOoqr3ZmAn4 VXN9Cepw7viDn2IKh1KtZV/yg X-Received: by 2002:a05:620a:318f:b0:765:a957:f526 with SMTP id bi15-20020a05620a318f00b00765a957f526mr5491563qkb.3.1690463739087; Thu, 27 Jul 2023 06:15:39 -0700 (PDT) X-Google-Smtp-Source: APBJJlH1DyY2M8hXAuCoIVwrMg350ou4HtJv049anJhsIv3IyMg4HxHTjRWByBzy/LHrzDeVZAZxLw== X-Received: by 2002:a05:620a:318f:b0:765:a957:f526 with SMTP id bi15-20020a05620a318f00b00765a957f526mr5491539qkb.3.1690463738744; Thu, 27 Jul 2023 06:15:38 -0700 (PDT) Received: from x1n (cpe5c7695f3aee0-cm5c7695f3aede.cpe.net.cable.rogers.com. [99.254.144.39]) by smtp.gmail.com with ESMTPSA id z5-20020a05620a100500b00767cf5d3faasm396971qkj.86.2023.07.27.06.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jul 2023 06:15:38 -0700 (PDT) Date: Thu, 27 Jul 2023 09:15:37 -0400 From: Peter Xu To: David Hildenbrand Cc: liubo , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hughd@google.com, willy@infradead.org Subject: Re: [PATCH] smaps: Fix the abnormal memory statistics obtained through /proc/pid/smaps Message-ID: References: <20230726073409.631838-1-liubo254@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 27, 2023 at 01:37:06PM +0200, David Hildenbrand wrote: > On Wed, Jul 26, 2023 at 9:40 AM liubo wrote: > > > > In commit 474098edac26 ("mm/gup: replace FOLL_NUMA by > > gup_can_follow_protnone()"), FOLL_NUMA was removed and replaced by > > the gup_can_follow_protnone interface. > > > > However, for the case where the user-mode process uses transparent > > huge pages, when analyzing the memory usage through > > /proc/pid/smaps_rollup, the obtained memory usage is not consistent > > with the RSS in /proc/pid/status. > > > > Related examples are as follows: > > cat /proc/15427/status > > VmRSS: 20973024 kB > > RssAnon: 20971616 kB > > RssFile: 1408 kB > > RssShmem: 0 kB > > > > cat /proc/15427/smaps_rollup > > 00400000-7ffcc372d000 ---p 00000000 00:00 0 [rollup] > > Rss: 14419432 kB > > Pss: 14418079 kB > > Pss_Dirty: 14418016 kB > > Pss_Anon: 14418016 kB > > Pss_File: 63 kB > > Pss_Shmem: 0 kB > > Anonymous: 14418016 kB > > LazyFree: 0 kB > > AnonHugePages: 14417920 kB > > > > The root cause is that the traversal In the page table, the number of > > pages obtained by smaps_pmd_entry does not include the pages > > corresponding to PROTNONE,resulting in a different situation. > > > > Thanks for reporting and debugging! > > > Therefore, when obtaining pages through the follow_trans_huge_pmd > > interface, add the FOLL_FORCE flag to count the pages corresponding to > > PROTNONE to solve the above problem. > > > > We really want to avoid the usage of FOLL_FORCE, and ideally limit it > to ptrace only. Fundamentally when removing FOLL_NUMA we did already assumed !FORCE is FOLL_NUMA. It means to me after the removal it's not possible to say in a gup walker that "it's not FORCEd, but I don't want to trigger NUMA but just get the page". Is that what we want? Shall we document that in FOLL_FORCE if we intended to enforce numa balancing as long as !FORCE? > > > Signed-off-by: liubo > > Fixes: 474098edac26 ("mm/gup: replace FOLL_NUMA by gup_can_follow_protnone()") > > --- > > fs/proc/task_mmu.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > > index c1e6531cb02a..ed08f9b869e2 100644 > > --- a/fs/proc/task_mmu.c > > +++ b/fs/proc/task_mmu.c > > @@ -571,8 +571,10 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr, > > bool migration = false; > > > > if (pmd_present(*pmd)) { > > - /* FOLL_DUMP will return -EFAULT on huge zero page */ > > - page = follow_trans_huge_pmd(vma, addr, pmd, FOLL_DUMP); > > + /* FOLL_DUMP will return -EFAULT on huge zero page > > + * FOLL_FORCE follow a PROT_NONE mapped page > > + */ > > + page = follow_trans_huge_pmd(vma, addr, pmd, FOLL_DUMP | FOLL_FORCE); > > } else if (unlikely(thp_migration_supported() && is_swap_pmd(*pmd))) { > > swp_entry_t entry = pmd_to_swp_entry(*pmd); > > Might do as an easy fix. But we really should get rid of that > absolutely disgusting usage of follow_trans_huge_pmd(). > > We don't need 99% of what follow_trans_huge_pmd() does here. > > Would the following also fix your issue? > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 507cd4e59d07..fc744964816e 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -587,8 +587,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr, > bool migration = false; > > if (pmd_present(*pmd)) { > - /* FOLL_DUMP will return -EFAULT on huge zero page */ > - page = follow_trans_huge_pmd(vma, addr, pmd, FOLL_DUMP); > + page = vm_normal_page_pmd(vma, addr, *pmd); > } else if (unlikely(thp_migration_supported() && is_swap_pmd(*pmd))) { > swp_entry_t entry = pmd_to_swp_entry(*pmd); > > It also skips the shared zeropage and pmd_devmap(), > > Otherwise, a simple pmd_page(*pmd) + is_huge_zero_pmd(*pmd) check will do, but I > suspect vm_normal_page_pmd() might be what we actually want to have here. > > Because smaps_pte_entry() properly checks for vm_normal_page(). There're indeed some very trivial detail in vm_normal_page_pmd() that's different, but maybe not so relevant. E.g., if (WARN_ON_ONCE(folio_ref_count(folio) <= 0)) return -ENOMEM; if (unlikely(!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page))) return -EREMOTEIO; I'm not sure whether the p2pdma page would matter in any form here. E.g., whether it can be mapped privately. -- Peter Xu