From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>, Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kasan-dev@googlegroups.com, linux-alpha@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: [PATCH 22/32] docs/vm: soft-dirty.txt: convert to ReST format
Date: Wed, 21 Mar 2018 21:22:38 +0200 [thread overview]
Message-ID: <1521660168-14372-23-git-send-email-rppt@linux.vnet.ibm.com> (raw)
In-Reply-To: <1521660168-14372-1-git-send-email-rppt@linux.vnet.ibm.com>
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
Documentation/vm/soft-dirty.txt | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/vm/soft-dirty.txt b/Documentation/vm/soft-dirty.txt
index 55684d1..cb0cfd6 100644
--- a/Documentation/vm/soft-dirty.txt
+++ b/Documentation/vm/soft-dirty.txt
@@ -1,34 +1,38 @@
- SOFT-DIRTY PTEs
+.. _soft_dirty:
- The soft-dirty is a bit on a PTE which helps to track which pages a task
+===============
+Soft-Dirty PTEs
+===============
+
+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 the task's PTEs.
- This is done by writing "4" into the /proc/PID/clear_refs file of the
+ This is done by writing "4" into the ``/proc/PID/clear_refs`` file of the
task in question.
2. Wait some time.
3. Read soft-dirty bits from the PTEs.
- This is done by reading from the /proc/PID/pagemap. The bit 55 of the
+ This is done by reading from the ``/proc/PID/pagemap``. The bit 55 of the
64-bit qword is the soft-dirty one. If set, the respective PTE was
written to since step 1.
- Internally, to do this tracking, the writable bit is cleared from PTEs
+Internally, to do this tracking, the writable bit is cleared from PTEs
when the soft-dirty bit is cleared. So, 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
+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 both writable and soft-dirty
bits on the PTE.
- While in most cases tracking memory changes by #PF-s is more than enough
+While in most cases tracking memory changes by #PF-s is more than enough
there is still a scenario when we can lose soft dirty bits -- a task
unmaps a previously mapped memory region and then maps a new one at exactly
the same place. When unmap is called, the kernel internally clears PTE values
@@ -36,7 +40,7 @@ including soft dirty bits. To notify user space application about such
memory region renewal the kernel always marks new memory regions (and
expanded regions) as soft dirty.
- This feature is actively used by the checkpoint-restore project. You
+This feature is actively used by the checkpoint-restore project. You
can find more details about it on http://criu.org
--
2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>, Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kasan-dev@googlegroups.com, linux-alpha@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: [PATCH 22/32] docs/vm: soft-dirty.txt: convert to ReST format
Date: Wed, 21 Mar 2018 21:22:38 +0200 [thread overview]
Message-ID: <1521660168-14372-23-git-send-email-rppt@linux.vnet.ibm.com> (raw)
In-Reply-To: <1521660168-14372-1-git-send-email-rppt@linux.vnet.ibm.com>
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
Documentation/vm/soft-dirty.txt | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/vm/soft-dirty.txt b/Documentation/vm/soft-dirty.txt
index 55684d1..cb0cfd6 100644
--- a/Documentation/vm/soft-dirty.txt
+++ b/Documentation/vm/soft-dirty.txt
@@ -1,34 +1,38 @@
- SOFT-DIRTY PTEs
+.. _soft_dirty:
- The soft-dirty is a bit on a PTE which helps to track which pages a task
+===============
+Soft-Dirty PTEs
+===============
+
+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 the task's PTEs.
- This is done by writing "4" into the /proc/PID/clear_refs file of the
+ This is done by writing "4" into the ``/proc/PID/clear_refs`` file of the
task in question.
2. Wait some time.
3. Read soft-dirty bits from the PTEs.
- This is done by reading from the /proc/PID/pagemap. The bit 55 of the
+ This is done by reading from the ``/proc/PID/pagemap``. The bit 55 of the
64-bit qword is the soft-dirty one. If set, the respective PTE was
written to since step 1.
- Internally, to do this tracking, the writable bit is cleared from PTEs
+Internally, to do this tracking, the writable bit is cleared from PTEs
when the soft-dirty bit is cleared. So, 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
+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 both writable and soft-dirty
bits on the PTE.
- While in most cases tracking memory changes by #PF-s is more than enough
+While in most cases tracking memory changes by #PF-s is more than enough
there is still a scenario when we can lose soft dirty bits -- a task
unmaps a previously mapped memory region and then maps a new one at exactly
the same place. When unmap is called, the kernel internally clears PTE values
@@ -36,7 +40,7 @@ including soft dirty bits. To notify user space application about such
memory region renewal the kernel always marks new memory regions (and
expanded regions) as soft dirty.
- This feature is actively used by the checkpoint-restore project. You
+This feature is actively used by the checkpoint-restore project. You
can find more details about it on http://criu.org
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>, Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kasan-dev@googlegroups.com, linux-alpha@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: [PATCH 22/32] docs/vm: soft-dirty.txt: convert to ReST format
Date: Wed, 21 Mar 2018 19:22:38 +0000 [thread overview]
Message-ID: <1521660168-14372-23-git-send-email-rppt@linux.vnet.ibm.com> (raw)
In-Reply-To: <1521660168-14372-1-git-send-email-rppt@linux.vnet.ibm.com>
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
Documentation/vm/soft-dirty.txt | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/vm/soft-dirty.txt b/Documentation/vm/soft-dirty.txt
index 55684d1..cb0cfd6 100644
--- a/Documentation/vm/soft-dirty.txt
+++ b/Documentation/vm/soft-dirty.txt
@@ -1,34 +1,38 @@
- SOFT-DIRTY PTEs
+.. _soft_dirty:
- The soft-dirty is a bit on a PTE which helps to track which pages a task
+=======+Soft-Dirty PTEs
+=======+
+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 the task's PTEs.
- This is done by writing "4" into the /proc/PID/clear_refs file of the
+ This is done by writing "4" into the ``/proc/PID/clear_refs`` file of the
task in question.
2. Wait some time.
3. Read soft-dirty bits from the PTEs.
- This is done by reading from the /proc/PID/pagemap. The bit 55 of the
+ This is done by reading from the ``/proc/PID/pagemap``. The bit 55 of the
64-bit qword is the soft-dirty one. If set, the respective PTE was
written to since step 1.
- Internally, to do this tracking, the writable bit is cleared from PTEs
+Internally, to do this tracking, the writable bit is cleared from PTEs
when the soft-dirty bit is cleared. So, 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
+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 both writable and soft-dirty
bits on the PTE.
- While in most cases tracking memory changes by #PF-s is more than enough
+While in most cases tracking memory changes by #PF-s is more than enough
there is still a scenario when we can lose soft dirty bits -- a task
unmaps a previously mapped memory region and then maps a new one at exactly
the same place. When unmap is called, the kernel internally clears PTE values
@@ -36,7 +40,7 @@ including soft dirty bits. To notify user space application about such
memory region renewal the kernel always marks new memory regions (and
expanded regions) as soft dirty.
- This feature is actively used by the checkpoint-restore project. You
+This feature is actively used by the checkpoint-restore project. You
can find more details about it on http://criu.org
--
2.7.4
next prev parent reply other threads:[~2018-03-21 19:29 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 19:22 [PATCH 00/32] docs/vm: convert to ReST format Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 01/32] docs/vm: active_mm.txt " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 02/32] docs/vm: balance: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 03/32] docs/vm: cleancache.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 04/32] docs/vm: frontswap.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 05/32] docs/vm: highmem.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 06/32] docs/vm: hmm.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 07/32] docs/vm: hugetlbpage.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 08/32] docs/vm: hugetlbfs_reserv.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 09/32] docs/vm: hwpoison.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 10/32] docs/vm: idle_page_tracking.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 11/32] docs/vm: ksm.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 12/32] docs/vm: mmu_notifier.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 13/32] docs/vm: numa_memory_policy.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 14/32] docs/vm: overcommit-accounting: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 15/32] docs/vm: page_frags " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 16/32] docs/vm: numa: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 17/32] docs/vm: pagemap.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 18/32] docs/vm: page_migration: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 19/32] docs/vm: page_owner: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 20/32] docs/vm: remap_file_pages.txt: conert " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 21/32] docs/vm: slub.txt: convert " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport [this message]
2018-03-21 19:22 ` [PATCH 22/32] docs/vm: soft-dirty.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 23/32] docs/vm: split_page_table_lock: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 24/32] docs/vm: swap_numa.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 25/32] docs/vm: transhuge.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 26/32] docs/vm: unevictable-lru.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 27/32] docs/vm: userfaultfd.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 28/32] docs/vm: z3fold.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 29/32] docs/vm: zsmalloc.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 30/32] docs/vm: zswap.txt: " Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 31/32] docs/vm: rename documentation files to .rst Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` [PATCH 32/32] docs/vm: add index.rst and link MM documentation to top level index Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-21 19:22 ` Mike Rapoport
2018-03-29 21:46 ` [PATCH 00/32] docs/vm: convert to ReST format Jonathan Corbet
2018-03-29 21:46 ` Jonathan Corbet
2018-03-29 21:46 ` Jonathan Corbet
2018-04-01 6:38 ` Mike Rapoport
2018-04-01 6:38 ` Mike Rapoport
2018-04-01 6:38 ` Mike Rapoport
2018-04-10 10:23 ` Mike Rapoport
2018-04-10 10:23 ` Mike Rapoport
2018-04-10 10:23 ` Mike Rapoport
2018-04-13 19:55 ` Jonathan Corbet
2018-04-13 19:55 ` Jonathan Corbet
2018-04-13 19:55 ` Jonathan Corbet
2018-04-13 20:21 ` Matthew Wilcox
2018-04-13 20:21 ` Matthew Wilcox
2018-04-13 20:21 ` Matthew Wilcox
2018-04-15 17:29 ` Mike Rapoport
2018-04-15 17:29 ` Mike Rapoport
2018-04-15 17:29 ` Mike Rapoport
2018-04-15 17:36 ` Mike Rapoport
2018-04-15 17:36 ` Mike Rapoport
2018-04-15 17:36 ` Mike Rapoport
2018-04-16 20:35 ` Jonathan Corbet
2018-04-16 20:35 ` Jonathan Corbet
2018-04-16 20:35 ` Jonathan Corbet
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=1521660168-14372-23-git-send-email-rppt@linux.vnet.ibm.com \
--to=rppt@linux.vnet.ibm.com \
--cc=aryabinin@virtuozzo.com \
--cc=corbet@lwn.net \
--cc=fenghua.yu@intel.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jhogan@kernel.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mattst88@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=ralf@linux-mips.org \
--cc=rth@twiddle.net \
--cc=tony.luck@intel.com \
--cc=viro@zeniv.linux.org.uk \
/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.