linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: SeongJae Park <sj@kernel.org>
Cc: akpm@linux-foundation.org, damon@lists.linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/damon: Validate if the pmd entry is present before accessing
Date: Thu, 18 Aug 2022 10:39:54 +0800	[thread overview]
Message-ID: <c9cde43f-d169-0a65-e69a-7b77c75322fd@linux.alibaba.com> (raw)
In-Reply-To: <20220818022947.94345-1-sj@kernel.org>



On 8/18/2022 10:29 AM, SeongJae Park wrote:
> Hi Baolin,
> 
> On Thu, 18 Aug 2022 09:05:58 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
> 
>>
>>
>> On 8/18/2022 12:09 AM, SeongJae Park wrote:
>>> Hi Baolin,
>>>
>>>
>>> Thank you always for your great patch!
>>>
>>> On Wed, 17 Aug 2022 14:21:12 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
>>>
>>>> The pmd_huge() is used to validate if the pmd entry is mapped by a huge
>>>> page, also including the case of non-present (migration or hwpoisoned)
>>>> pmd entry on arm64 or x86 architectures. Thus we should validate if it
>>>> is present before making the pmd entry old or getting young state,
>>>> otherwise we can not get the correct corresponding page.
>>>
>>> Maybe I'm missing something, but... I'm unsure if the page is present or not
>>> really matters from the perspective of access checking.  In the case, DAMON
>>> could simply report the page has accessed once for the first check after the
>>> page being non-present if it really accessed before, and then report the page
>>> as not accessed, which is true.
>>
>> Yes, that's the patch's goal to make the accesses correct. However if
>> the PMD entry is not present, we can not get the correct page object by
>> pmd_pfn(*pmd), since the non-present pmd entry will contain swap type
>> and swap offset with below format on ARM64, that means the pfn number is
>> saved in bits 8-57 in a migration or poisoned entry, but pmd_pfn() still
>> treat bits 12-47 as the pfn number on ARM64, which may get an incorrect
>> page struct (also maybe is NULL by pfn_to_online_page()) to make the
>> access statistics incorrect.
>>
>> /*
>>    * Encode and decode a swap entry:
>>    *	bits 0-1:	present (must be zero)
>>    *	bits 2:		remember PG_anon_exclusive
>>    *	bits 3-7:	swap type
>>    *	bits 8-57:	swap offset
>>    *	bit  58:	PTE_PROT_NONE (must be zero)
>>    */
>>
>>
>> Moreoever I don't think we should still waste time to get the page of
>> the non-present entry, just treat it as not-accessed and skip it, that
>> keeps consistent with non-present pte level entry.
>>
>> Does that make sense for you? Thanks.
> 
> Yes, that totally makes sense.  Thank you very much for the kind answer.  I
> think it would be great if we could put the detailed explanation in the commit
> message.  Could you please update the commit message and post v2 of the patch?

Sure, will update the commit message to make it more clear and I think 
that can also answer Andrew's concern.

> 
> Reviewed-by: SeongJae Park <sj@kernel.org>

Thanks.


  reply	other threads:[~2022-08-18  2:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17  6:21 Baolin Wang
2022-08-17 16:07 ` Andrew Morton
2022-08-17 16:09 ` SeongJae Park
2022-08-18  1:05   ` Baolin Wang
2022-08-18  2:29     ` SeongJae Park
2022-08-18  2:39       ` Baolin Wang [this message]
2022-08-18  2:41 ` Muchun Song
2022-08-18  2:57   ` Baolin Wang
2022-08-18  3:39     ` Muchun Song
2022-08-18  5:07       ` Baolin Wang
2022-08-18  5:12         ` Muchun Song
2022-08-18  5:45           ` Baolin Wang

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=c9cde43f-d169-0a65-e69a-7b77c75322fd@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sj@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox