linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: shu wang <malate_wangshu@hotmail.com>
Cc: Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [Bug 211287] New: Softdirty bit does not work with hugetlb
Date: Mon, 1 Feb 2021 17:02:11 -0800	[thread overview]
Message-ID: <de51c265-6028-b3cd-33be-7b469a93881f@oracle.com> (raw)
In-Reply-To: <6aa94855-c204-83a6-98e5-2841f1b00b16@oracle.com>

On 1/22/21 1:50 PM, Mike Kravetz wrote:
> On 1/22/21 10:42 AM, shu wang wrote:
>> Our use case is:
>> We maps both PMEM and hugetlb DRAM to process’s address space to provide large amount of memory to the application. Periodically, we clear the soft dirty bit by writing ‘4’ to the clear_refs. Then, we check the page’s soft dirty bit from pagemap and use this information to track write activity to memory. We migrate the data between DRAM and PMEM based the write activity for better performance.
>>
> 
> Thank you for the information!
> 
> If someone does not beat me to it, I should be able to look at this next week.

Just a quick update.

The /proc clear_refs code handles THP pages and 'normal' pages.  There is
no check/processing for hugetlb pages.  All the code will do is clear the
VM_SOFTDIRTY vma flag and vma_set_page_prot.  None of the individual ptes
or page flags are touched.

The only soft dirty checking done by the /proc pagemap code is at the vma
level.  It checks the VM_SOFTDIRTY flag.   It does not look for soft dirty
on the individual ptes.

That explains the behavior described in the bug report.

With a quick and dirty hack I could make the code work in limited testing.
Much work remains.

If anyone wants to jump in and help, feel free.
-- 
Mike Kravetz


      reply	other threads:[~2021-02-02  1:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22  0:58 [Bug 211287] New: Softdirty bit does not work with hugetlb Mike Kravetz
2021-01-22 18:42 ` shu wang
2021-01-22 21:50   ` Mike Kravetz
2021-02-02  1:02     ` Mike Kravetz [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=de51c265-6028-b3cd-33be-7b469a93881f@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=malate_wangshu@hotmail.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).