All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	"Zi Yan" <ziy@nvidia.com>, "Vlastimil Babka" <vbabka@suse.cz>,
	"Alexey Dobriyan" <adobriyan@gmail.com>,
	"Michal Hocko" <mhocko@suse.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Yang Shi" <yang.shi@linux.alibaba.com>
Subject: Re: [PATCH] /proc/PID/smaps: Add PMD migration entry parsing
Date: Wed, 01 Apr 2020 14:20:40 +0800	[thread overview]
Message-ID: <87a73viv5z.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <a2ee2441-8ac7-84d2-8c7d-e28d80a6c413@yandex-team.ru> (Konstantin Khlebnikov's message of "Wed, 1 Apr 2020 09:03:45 +0300")

Konstantin Khlebnikov <khlebnikov@yandex-team.ru> writes:

> On 01/04/2020 05.31, Huang, Ying wrote:
>> Konstantin Khlebnikov <khlebnikov@yandex-team.ru> writes:
>>
>>> On 31/03/2020 11.56, Huang, Ying wrote:
>>>> From: Huang Ying <ying.huang@intel.com>
>>>>
>>>> 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" <ying.huang@intel.com>
>>>> Cc: Andrea Arcangeli <aarcange@redhat.com>
>>>> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>>>> Cc: Zi Yan <ziy@nvidia.com>
>>>> Cc: Vlastimil Babka <vbabka@suse.cz>
>>>> Cc: Alexey Dobriyan <adobriyan@gmail.com>
>>>> Cc: Michal Hocko <mhocko@suse.com>
>>>> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>>> Cc: "Jérôme Glisse" <jglisse@redhat.com>
>>>> Cc: Yang Shi <yang.shi@linux.alibaba.com>
>>>> ---
>>>>    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.

Sounds reasonable!  Will revise the code.  Thanks!

Best Regards,
Huang, Ying

>>
>> 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;
>>>>    	}
>>>>


  reply	other threads:[~2020-04-01  6:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31  8:56 [PATCH] /proc/PID/smaps: Add PMD migration entry parsing Huang, Ying
2020-03-31  9:51 ` Konstantin Khlebnikov
2020-04-01  2:31   ` Huang, Ying
2020-04-01  6:03     ` Konstantin Khlebnikov
2020-04-01  6:20       ` Huang, Ying [this message]
2020-03-31 12:24 ` Zi Yan
2020-04-01  2:24   ` Huang, Ying
2020-04-01  2:42     ` Zi Yan
2020-04-02  1:49   ` Huang, Ying
2020-04-01 23:04 ` Andrew Morton
2020-04-02  1:42   ` Huang, Ying
2020-04-02  6:27   ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a73viv5z.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=aarcange@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jglisse@redhat.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=vbabka@suse.cz \
    --cc=yang.shi@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.