Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp271299ybb; Tue, 31 Mar 2020 23:06:15 -0700 (PDT) X-Google-Smtp-Source: APiQypKbhMGYN+pF+lL9zd5ywd5IRJn7aVNNgv67sIvN9r1Kyf636YIKdo2epkmvzfTX5Afq8/JM X-Received: by 2002:a05:6808:b1a:: with SMTP id s26mr1631179oij.150.1585721175723; Tue, 31 Mar 2020 23:06:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585721175; cv=none; d=google.com; s=arc-20160816; b=0FnW2wVmpNHeizKnNP9bb8hSJ3N9FZsNwmt8D3fqKiNhDON7sQmWn5AZ4ID1MBlYk+ /F0Vi3eq2+/DQxIsKv9blPrxjYS8GH0wxSLatd7elIA23NR7zL9OEa9CO/ECCDlzkEJw UdbHJiNmyWGm3mSrezpC2MM7Q0DEyLQyCl6xjZPIr03V1QMFldkZJaLdftfGNCBKWim3 PeXyGHFNfT13bMZrQbAXI7k9kVEtZYcFUn5oNKHJVkPWWqqIXoY2aGmQwwL0Cl5oZYtX jTbuoEcXv4hzutCxmjUd/yueUGuqcP7zkEHB5V4sKRr5qPyI9s6VWRqPUhuOcuxeouEi QxRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=1bAHvSB3kmRgmi7tuFuA6Fe/PqgZGvIRR5VswNBqy+Q=; b=huIHORIibpqbEbr6Olq5uBdWHNQuP9l+hr6nf8QeseZMG/3gNLUryLW2xoyRtvIdwW tKTknmx34ORxI/F+DauJYritQhELEU5HeAke1IIXJQJjRBHmllLO1OiPrw0ccvbucxfS HfUAyEQmXVMG+5Yhtbekk8dOd6lq5Kd7H0f7+SSaZpf58YrvV2MedmQOb+Jso3nzymzs 8QvM5qsL19fzmAXsmVUQP1AAmNHKgl4FVBrOQEdbO60UNOYvQs8FmDVvkwbaTmRckUd7 uW0bNQqM7DERD8G5pWIOet1dNXeF6EYHiLE3gRFgvEXUh1FsIfJ7BozrkPqZ3jgEibeT 8cyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=YfALPzGA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e6si560625oiy.229.2020.03.31.23.05.55; Tue, 31 Mar 2020 23:06:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=YfALPzGA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731764AbgDAGDv (ORCPT + 99 others); Wed, 1 Apr 2020 02:03:51 -0400 Received: from forwardcorp1j.mail.yandex.net ([5.45.199.163]:41270 "EHLO forwardcorp1j.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731721AbgDAGDu (ORCPT ); Wed, 1 Apr 2020 02:03:50 -0400 Received: from mxbackcorp1j.mail.yandex.net (mxbackcorp1j.mail.yandex.net [IPv6:2a02:6b8:0:1619::162]) by forwardcorp1j.mail.yandex.net (Yandex) with ESMTP id 9CB872E15AB; Wed, 1 Apr 2020 09:03:46 +0300 (MSK) Received: from myt5-70c90f7d6d7d.qloud-c.yandex.net (myt5-70c90f7d6d7d.qloud-c.yandex.net [2a02:6b8:c12:3e2c:0:640:70c9:f7d]) by mxbackcorp1j.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id 5s7A5tV1Tc-3jZeji0t; Wed, 01 Apr 2020 09:03:46 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1585721026; bh=1bAHvSB3kmRgmi7tuFuA6Fe/PqgZGvIRR5VswNBqy+Q=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=YfALPzGAC6zjrqj4KLwLgQrUp2Jgykdgm5P/IsAz49/3PlbuZQCVHf0jt3Y8IDSWG 2W/G0oynp9cNGWT37lf1aWhTPshOpu2Va5aUs06ssAtNvEMpnqa7bazieO2vVAMD3A upWnmJjWk5+mxuYs7aOHiICf/FtpjVsj5vJwYRis= Authentication-Results: mxbackcorp1j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from unknown (unknown [2a02:6b8:b080:7613::1:5]) by myt5-70c90f7d6d7d.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id zG2YiQjTrL-3jWWQ0xO; Wed, 01 Apr 2020 09:03:45 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: [PATCH] /proc/PID/smaps: Add PMD migration entry parsing To: "Huang, Ying" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , "Kirill A . Shutemov" , Zi Yan , Vlastimil Babka , Alexey Dobriyan , Michal Hocko , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Yang Shi References: <20200331085604.1260162-1-ying.huang@intel.com> <49386753-5984-f708-4153-e9c6de632439@yandex-team.ru> <87mu7whr88.fsf@yhuang-dev.intel.com> From: Konstantin Khlebnikov Message-ID: Date: Wed, 1 Apr 2020 09:03:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <87mu7whr88.fsf@yhuang-dev.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/04/2020 05.31, Huang, Ying wrote: > Konstantin Khlebnikov writes: > >> On 31/03/2020 11.56, Huang, Ying wrote: >>> From: Huang Ying >>> >>> Now, when read /proc/PID/smaps, the PMD migration entry in page table is simply >>> ignored. To improve the accuracy of /proc/PID/smaps, its parsing and processing >>> is added. >>> >>> Signed-off-by: "Huang, Ying" >>> Cc: Andrea Arcangeli >>> Cc: Kirill A. Shutemov >>> Cc: Zi Yan >>> Cc: Vlastimil Babka >>> Cc: Alexey Dobriyan >>> Cc: Michal Hocko >>> Cc: Konstantin Khlebnikov >>> Cc: "Jérôme Glisse" >>> Cc: Yang Shi >>> --- >>> fs/proc/task_mmu.c | 16 ++++++++++++---- >>> 1 file changed, 12 insertions(+), 4 deletions(-) >>> >>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c >>> index 8d382d4ec067..b5b3aef8cb3b 100644 >>> --- a/fs/proc/task_mmu.c >>> +++ b/fs/proc/task_mmu.c >>> @@ -548,8 +548,17 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr, >>> bool locked = !!(vma->vm_flags & VM_LOCKED); >>> struct page *page; >> >> struct page *page = NULL; > > Looks good. Will do this in the next version. > >>> - /* FOLL_DUMP will return -EFAULT on huge zero page */ >>> - page = follow_trans_huge_pmd(vma, addr, pmd, FOLL_DUMP); >>> + if (pmd_present(*pmd)) { >>> + /* FOLL_DUMP will return -EFAULT on huge zero page */ >>> + page = follow_trans_huge_pmd(vma, addr, pmd, FOLL_DUMP); >>> + } else if (unlikely(is_swap_pmd(*pmd))) { >>> + swp_entry_t entry = pmd_to_swp_entry(*pmd); >>> + >>> + VM_BUG_ON(!is_migration_entry(entry)); >>> + page = migration_entry_to_page(entry); >> >> if (is_migration_entry(entry)) >> page = migration_entry_to_page(entry); >> >> Seems safer and doesn't add much code. > > With this, we lose an opportunity to capture some bugs during debugging. > Right? You can keep VM_BUG_ON or VM_WARN_ON_ONCE Off-by-page in statistics isn't a big deal and not a good reason to crash (even debug) kernel. But for normal build should use safe behaviour if this isn't hard. > > Best Regards, > Huang, Ying > >>> + } else { >>> + return; >>> + } >>> if (IS_ERR_OR_NULL(page)) >>> return; >>> if (PageAnon(page)) >>> @@ -578,8 +587,7 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, >>> ptl = pmd_trans_huge_lock(pmd, vma); >>> if (ptl) { >>> - if (pmd_present(*pmd)) >>> - smaps_pmd_entry(pmd, addr, walk); >>> + smaps_pmd_entry(pmd, addr, walk); >>> spin_unlock(ptl); >>> goto out; >>> } >>>