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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5CDCC433EF for ; Fri, 12 Nov 2021 07:41:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3C63360FDA for ; Fri, 12 Nov 2021 07:41:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3C63360FDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C5F786B0074; Fri, 12 Nov 2021 02:41:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C0E486B0078; Fri, 12 Nov 2021 02:41:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD63B6B007B; Fri, 12 Nov 2021 02:41:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 9E1246B0074 for ; Fri, 12 Nov 2021 02:41:28 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 50FA11849084E for ; Fri, 12 Nov 2021 07:41:28 +0000 (UTC) X-FDA: 78799483056.11.6C91A09 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 84441900026D for ; Fri, 12 Nov 2021 07:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636702886; 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: in-reply-to:in-reply-to:references:references; bh=LmIYVgQWINOS/4GPj7vitVLbYIw2tQyXzHOCJlZ5erE=; b=Vz+6nh6x7b7hn/rYKdFh+DUGE4YLpOGvZbMcAnEd2X/YqH/IB3CgV6WUgzTiWi6iYCFlkG RNuemV3e927QeAf3W1vUiYqp8VqGT2jTCi+XIkmUfJ589Zfla80dqFlAG+R7UKmDUwz/qf X4jnpTn+Pt0wSysoA+RdxGEQPxPKOrc= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-4bbkHdTLOhy840DQrMUOow-1; Fri, 12 Nov 2021 02:41:23 -0500 X-MC-Unique: 4bbkHdTLOhy840DQrMUOow-1 Received: by mail-pl1-f199.google.com with SMTP id e9-20020a170902ed8900b00143a3f40299so742068plj.20 for ; Thu, 11 Nov 2021 23:41:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=LmIYVgQWINOS/4GPj7vitVLbYIw2tQyXzHOCJlZ5erE=; b=HEiGdo48ujzXy7ZheofMgCF15GJ+U+c58ahzB/LXMiaNJoRHPP7uUJTANnZNgY8HZk 7jvSPGsSgYz9wK1U+7MOOUuirTtlekuBJ5Kpg+UTVxnr5rjQXgr4SuQGMKR0t/mcplR1 lkZxPlWgHhvCcqKFSEQhDnSN11UdrNVj07mB7SpoPHWuiMe3M7QUqM33TPELa/HdS2qu KFqxMyMvWiwy467LaSTD6100F5I6PDLsApho6p7fWOnPWo76S3mFvMtKtwGJcaviCinq /R/5JAooJlyedJgaIb3BJ8A9VBpNs5d8qTbG+QM3LUWacvaJaMJDqSvfxerFgdM2zpOk 2yiA== X-Gm-Message-State: AOAM532mtXaj5LnGEOLqwODTqv5kLzjwDlJ49AZwUDsgScEG3lMDQymn 5bcXcwbabOfohiyugwtUL67uMx+XaJkvQHtusMF0tOP6lobLtQ48JPmyt1FoweEbfxpAH/2fPSV c1VPV1DnrguM= X-Received: by 2002:a17:90a:6583:: with SMTP id k3mr34161329pjj.147.1636702882450; Thu, 11 Nov 2021 23:41:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwYU6pU2s+wZvuogOQ3U+/jYMIOI6bwB5fRtApXzVv4JQPB8e07gFu11espB+vV+ZhMupPz8w== X-Received: by 2002:a17:90a:6583:: with SMTP id k3mr34161288pjj.147.1636702882161; Thu, 11 Nov 2021 23:41:22 -0800 (PST) Received: from xz-m1.local ([94.177.118.141]) by smtp.gmail.com with ESMTPSA id w5sm5755612pfu.219.2021.11.11.23.41.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 23:41:21 -0800 (PST) Date: Fri, 12 Nov 2021 15:41:14 +0800 From: Peter Xu To: Mina Almasry Cc: David Hildenbrand , Matthew Wilcox , "Paul E . McKenney" , Yu Zhao , Jonathan Corbet , Andrew Morton , Ivan Teterevkov , Florian Schmidt , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4] mm: Add PM_HUGE_THP_MAPPING to /proc/pid/pagemap Message-ID: References: <20211107235754.1395488-1-almasrymina@google.com> <793685d2-be3f-9a74-c9a3-65c486e0ef1f@redhat.com> <8032a24c-3800-16e5-41b7-5565e74d3863@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 84441900026D X-Stat-Signature: 7ooray6tmu1z4amoz673jgsqawep57j9 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Vz+6nh6x; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf29.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-HE-Tag: 1636702887-872494 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 Wed, Nov 10, 2021 at 09:42:25AM -0800, Mina Almasry wrote: > Sorry, yes I should update the commit message with this info. The > issues with smaps are: > 1. Performance: I've pinged our network service folks to obtain a > rough perf comparison but I haven't been able to get one. I can try to > get a performance measurement myself but Peter seems to be also seeing > this. No I was not seeing any real issues in my environment, but I remembered people complaining about it because smaps needs to walk the whole memory of the process, then if one program is only interested in some small portion of the whole memory, it'll be slow because smaps will still need to walk all the memory anyway. > 2. smaps output is human readable and a bit convoluted for userspace to parse. IMHO this is not a major issue. AFAIK lots of programs will still try to parse human readable output like smaps to get some solid numbers. It's just that it'll be indeed an perf issue if it's only a part of the memory that is of interest. Could we consider exporting a new smaps interface that: 1. allows to specify a range of memory, and, 2. expose information as "struct mem_size_stats" in binary format (we may want to replace "unsigned long" with "u64", then also have some versioning or having a "size" field for the struct, though; seems doable) I'm wondering whether this could be helpful in even more scenarios. -- Peter Xu