From: Pavel Emelyanov <xemul@parallels.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] mm: Soft-dirty bits for user memory changes tracking
Date: Fri, 12 Apr 2013 17:14:03 +0400 [thread overview]
Message-ID: <5168089B.7060305@parallels.com> (raw)
In-Reply-To: <20130411142417.bb58d519b860d06ab84333c2@linux-foundation.org>
On 04/12/2013 01:24 AM, Andrew Morton wrote:
> On Thu, 11 Apr 2013 15:30:00 +0400 Pavel Emelyanov <xemul@parallels.com> wrote:
>
>> The soft-dirty is a bit on a PTE which helps to track which pages a task
>> writes to. In order to do this tracking one should
>>
>> 1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
>> 2. Wait some time.
>> 3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries)
>>
>> To do this tracking, the writable bit is cleared from PTEs when the
>> soft-dirty bit is. Thus, after this, when the task tries to modify a page
>> at some virtual address the #PF occurs and the kernel sets the soft-dirty
>> bit on the respective PTE.
>>
>> Note, that although all the task's address space is marked as r/o after the
>> soft-dirty bits clear, the #PF-s that occur after that are processed fast.
>> This is so, since the pages are still mapped to physical memory, and thus
>> all the kernel does is finds this fact out and puts back writable, dirty
>> and soft-dirty bits on the PTE.
>>
>> Another thing to note, is that when mremap moves PTEs they are marked with
>> soft-dirty as well, since from the user perspective mremap modifies the
>> virtual memory at mremap's new address.
>>
>> ...
>>
>> +config MEM_SOFT_DIRTY
>> + bool "Track memory changes"
>> + depends on CHECKPOINT_RESTORE && X86
>
> I guess we can add the CHECKPOINT_RESTORE dependency for now, but it is
> a general facility and I expect others will want to get their hands on
> it for unrelated things.
OK. Just tell me when you need the dependency removing patch.
>>From that perspective, the dependency on X86 is awful. What's the
> problem here and what do other architectures need to do to be able to
> support the feature?
The problem here is that I don't know what free bits are available on
page table entries on other architectures. I was about to resolve this
for ARM very soon, but for the rest of them I need help from other people.
> You have a test application, I assume. It would be helpful if we could
> get that into tools/testing/selftests.
If a very stupid 10-lines test is OK, then I can cook a patch with it.
Other than this I test this using the whole CRIU project, which is too
big for inclusion.
Thanks,
Pavel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Emelyanov <xemul@parallels.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] mm: Soft-dirty bits for user memory changes tracking
Date: Fri, 12 Apr 2013 17:14:03 +0400 [thread overview]
Message-ID: <5168089B.7060305@parallels.com> (raw)
In-Reply-To: <20130411142417.bb58d519b860d06ab84333c2@linux-foundation.org>
On 04/12/2013 01:24 AM, Andrew Morton wrote:
> On Thu, 11 Apr 2013 15:30:00 +0400 Pavel Emelyanov <xemul@parallels.com> wrote:
>
>> The soft-dirty is a bit on a PTE which helps to track which pages a task
>> writes to. In order to do this tracking one should
>>
>> 1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
>> 2. Wait some time.
>> 3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries)
>>
>> To do this tracking, the writable bit is cleared from PTEs when the
>> soft-dirty bit is. Thus, after this, when the task tries to modify a page
>> at some virtual address the #PF occurs and the kernel sets the soft-dirty
>> bit on the respective PTE.
>>
>> Note, that although all the task's address space is marked as r/o after the
>> soft-dirty bits clear, the #PF-s that occur after that are processed fast.
>> This is so, since the pages are still mapped to physical memory, and thus
>> all the kernel does is finds this fact out and puts back writable, dirty
>> and soft-dirty bits on the PTE.
>>
>> Another thing to note, is that when mremap moves PTEs they are marked with
>> soft-dirty as well, since from the user perspective mremap modifies the
>> virtual memory at mremap's new address.
>>
>> ...
>>
>> +config MEM_SOFT_DIRTY
>> + bool "Track memory changes"
>> + depends on CHECKPOINT_RESTORE && X86
>
> I guess we can add the CHECKPOINT_RESTORE dependency for now, but it is
> a general facility and I expect others will want to get their hands on
> it for unrelated things.
OK. Just tell me when you need the dependency removing patch.
>>From that perspective, the dependency on X86 is awful. What's the
> problem here and what do other architectures need to do to be able to
> support the feature?
The problem here is that I don't know what free bits are available on
page table entries on other architectures. I was about to resolve this
for ARM very soon, but for the rest of them I need help from other people.
> You have a test application, I assume. It would be helpful if we could
> get that into tools/testing/selftests.
If a very stupid 10-lines test is OK, then I can cook a patch with it.
Other than this I test this using the whole CRIU project, which is too
big for inclusion.
Thanks,
Pavel
next prev parent reply other threads:[~2013-04-12 13:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-11 11:28 [PATCH 0/5] mm: Ability to monitor task memory changes (v3) Pavel Emelyanov
2013-04-11 11:28 ` Pavel Emelyanov
2013-04-11 11:28 ` [PATCH 1/5] clear_refs: Sanitize accepted commands declaration Pavel Emelyanov
2013-04-11 11:28 ` Pavel Emelyanov
2013-04-11 21:17 ` Andrew Morton
2013-04-11 21:17 ` Andrew Morton
2013-04-11 11:29 ` [PATCH 2/5] clear_refs: Introduce private struct for mm_walk Pavel Emelyanov
2013-04-11 11:29 ` Pavel Emelyanov
2013-04-11 11:29 ` [PATCH 3/5] pagemap: Introduce pagemap_entry_t without pmshift bits Pavel Emelyanov
2013-04-11 11:29 ` Pavel Emelyanov
2013-04-11 11:29 ` [PATCH 4/5] pagemap: Introduce the /proc/PID/pagemap2 file Pavel Emelyanov
2013-04-11 11:29 ` Pavel Emelyanov
2013-04-11 21:19 ` Andrew Morton
2013-04-11 21:19 ` Andrew Morton
2013-04-12 13:10 ` Pavel Emelyanov
2013-04-12 13:10 ` Pavel Emelyanov
2013-05-02 17:08 ` Matt Helsley
2013-05-02 17:08 ` Matt Helsley
2013-05-04 9:47 ` Pavel Emelyanov
2013-05-04 9:47 ` Pavel Emelyanov
2013-04-11 11:30 ` [PATCH 5/5] mm: Soft-dirty bits for user memory changes tracking Pavel Emelyanov
2013-04-11 11:30 ` Pavel Emelyanov
2013-04-11 21:24 ` Andrew Morton
2013-04-11 21:24 ` Andrew Morton
2013-04-12 13:14 ` Pavel Emelyanov [this message]
2013-04-12 13:14 ` Pavel Emelyanov
2013-04-15 21:46 ` Andrew Morton
2013-04-15 21:46 ` Andrew Morton
2013-04-15 23:57 ` Stephen Rothwell
2013-04-16 19:58 ` Pavel Emelyanov
2013-04-16 19:58 ` Pavel Emelyanov
2013-04-12 15:53 ` [PATCH 6/5] selftest: Add simple test for soft-dirty bit Pavel Emelyanov
2013-04-12 15:53 ` Pavel Emelyanov
2013-04-16 19:51 ` [PATCH 7/5] mem-soft-dirty: Reshuffle CONFIG_ options to be more Arch-friendly Pavel Emelyanov
2013-04-16 19:51 ` Pavel Emelyanov
2013-04-16 23:24 ` Stephen Rothwell
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=5168089B.7060305@parallels.com \
--to=xemul@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 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.