From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
To: SeongJae Park <sj@kernel.org>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: DAMON: problems when running DAMON on ARM64 with 'transparent_hugepage' enabled
Date: Mon, 8 Nov 2021 20:09:37 +0800 [thread overview]
Message-ID: <a2fb10bd-b44a-350e-f693-82ecfa6f54a8@huawei.com> (raw)
In-Reply-To: <20211105135748.32729-1-sj@kernel.org>
Hi SeongJae,
Thanks for your reply !
On 2021/11/5 21:57, SeongJae Park wrote:
> Hi Xiongfeng,
>
> On Wed, 27 Oct 2021 08:06:36 +0000 SeongJae Park <sj@kernel.org> wrote:
>
>> Hello Xiongfeng,
>>
>> On Wed, 27 Oct 2021 14:14:57 +0800 Xiongfeng Wang <wangxiongfeng2@huawei.com> wrote:
>>
>>> Sorry, I forgot to Cc the maillist. Cc it in this mail.
>>>
>>> On 2021/10/27 10:19, Xiongfeng Wang wrote:
>>>> Hi SeongJae,
>>>>
>>>> Sorry to disturb you. It's just that I came across some problems when running
>>>> DAMON, but still didn't find the solution after several days.
>>
>> You're not disturbing but helping me! Please don't say so! :)
>>
>>>>
>>>> A short description is that the result of DAMON is not as expected when running
>>>> on ARM64 with 'transparent_hugepage' enabled. But the result is correct when
>>>> 'transparent_hugepage' is disabled.
>>>>
>>>> The following are the steps I came across the problems.
>>>> 1. Firstly, I use 'damo record' to sample the 'stairs' demo.
>>>> damo record "./masim ./configs/stairs.cfg"
>>>> 2. Then I use 'damo report' to show the results.
>>>> damo report heats --address_range xxx xxx --time_range xxx xxx --heatmap
>>>> stdout --stdout_heatmap_color emotion
>>>> The result doesn't show like a stair. I wrote a userspace demo to access a
>>>> certain address range in loop and use DAMON to sample the demo. I added
>>>> trace_print in 'damon_va_check_access()' and found out the pages in the address
>>>> range are not always detected as accessed, which is not expected. When I disable
>>>> transparent_hugepage by chance, the pages are marked as accessed. Then I test
>>>> the 'stairs' demo again, the result is correct. It seems that, only when
>>>> transparent_hugepage' is disabled, the access check works. I don't know where
>>>> the bug is, the software or the hardware ? Appreciate it if you have time to
>>>> reply. Thanks !
>>
>> Thank you for this report! I have a theory, but would like to test first.
>> Will check and get back to you soon.
>
> Sorry for late response. I also confirmed the issue is reproducible on my
> ARM64 test machine. My theory is, enabling THP reduced page table walks, and
> therefore the PTE Accessed bits are not frequently updated. To verify this, I
> made below experimental change. After applying the change on my test machine,
> I was able to show the expected access pattern regardless of THP enablement.
>
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
> @@ -429,6 +429,7 @@ void damon_va_prepare_access_checks(struct damon_ctx *ctx)
> continue;
> damon_for_each_region(r, t)
> damon_va_prepare_access_check(ctx, mm, r);
> + flush_tlb_mm(mm);
> mmput(mm);
> }
> }
>
> Could you please test this on your machine and let me know the result?
Yes, it works. After I add 'flush_tlb_mm()' as above, the result is as expected.
>
> Again, please note that this change is only for proof of the theory, rather
> than the complete fix.
Thanks for let me know. I will wait for the official version.
Thanks,
Xiongfeng
>
>
> Thanks,
> SJ
>
>>
>>
>> Thanks,
>> SJ
>>
>>>>
>>>> Thanks,
>>>> Xiongfeng
> .
>
prev parent reply other threads:[~2021-11-08 12:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5524985d-9494-db74-4870-2b9879b8f7fd@huawei.com>
2021-10-27 6:14 ` DAMON: problems when running DAMON on ARM64 with 'transparent_hugepage' enabled Xiongfeng Wang
2021-10-27 8:06 ` SeongJae Park
2021-11-05 13:57 ` SeongJae Park
2021-11-08 12:09 ` Xiongfeng Wang [this message]
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=a2fb10bd-b44a-350e-f693-82ecfa6f54a8@huawei.com \
--to=wangxiongfeng2@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sj@kernel.org \
--cc=wangkefeng.wang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).