All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20160523214942.GA79646@black.fi.intel.com>

diff --git a/a/1.txt b/N1/1.txt
index ff0d5fe..ad01121 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -46,7 +46,7 @@ On Mon, May 23, 2016 at 04:13:03PM -0400, Rik van Riel wrote:
 > I can see a few alternatives here:
 > 
 > 1) huge pmd collapsing takes both the pmd lock and the pte lock,
->    preventing pte updates from happening simultaneously
+>    preventing pte updates from happening simultaneously
 
 That's what we do now and that's not enough.
 
@@ -58,11 +58,11 @@ That's huge hit on scalability.
 
 > 
 > 2) code that (re-)acquires the pte lock can read a sequence number
->    at the pmd level, check that it did not change after the
->    pte lock has been acquired, and abort if it has - I believe most
->    of the code that re-acquires the pte lock already knows how to
->    abort if somebody else touched the pte while it was looking
->    elsewhere
+>    at the pmd level, check that it did not change after the
+>    pte lock has been acquired, and abort if it has - I believe most
+>    of the code that re-acquires the pte lock already knows how to
+>    abort if somebody else touched the pte while it was looking
+>    elsewhere
 
 So, every pmd_lock() (and other means we take the lock) should bump the
 sequence number and we need to be able to read stable result  outside
@@ -79,9 +79,3 @@ And I'm not convinced the hassle worth the gain.
 
 -- 
  Kirill A. Shutemov
-
---
-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>
diff --git a/a/content_digest b/N1/content_digest
index 0baa4aa..3ab9cf3 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -77,7 +77,7 @@
  "> I can see a few alternatives here:\n"
  "> \n"
  "> 1) huge pmd collapsing takes both the pmd lock and the pte lock,\n"
- ">    preventing pte updates from happening simultaneously\n"
+ "> \302\240 \302\240preventing pte updates from happening simultaneously\n"
  "\n"
  "That's what we do now and that's not enough.\n"
  "\n"
@@ -89,11 +89,11 @@
  "\n"
  "> \n"
  "> 2) code that (re-)acquires the pte lock can read a sequence number\n"
- ">    at the pmd level, check that it did not change after the\n"
- ">    pte lock has been acquired, and abort if it has - I believe most\n"
- ">    of the code that re-acquires the pte lock already knows how to\n"
- ">    abort if somebody else touched the pte while it was looking\n"
- ">    elsewhere\n"
+ "> \302\240 \302\240at the pmd level, check that it did not change after the\n"
+ "> \302\240 \302\240pte lock has been acquired, and abort if it has - I believe most\n"
+ "> \302\240 \302\240of the code that re-acquires the pte lock already knows how to\n"
+ "> \302\240 \302\240abort if somebody else touched the pte while it was looking\n"
+ "> \302\240 \302\240elsewhere\n"
  "\n"
  "So, every pmd_lock() (and other means we take the lock) should bump the\n"
  "sequence number and we need to be able to read stable result  outside\n"
@@ -109,12 +109,6 @@
  "> considering a race with other pte-level manipulations requires that).\n"
  "\n"
  "-- \n"
- " Kirill A. Shutemov\n"
- "\n"
- "--\n"
- "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
- "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
- "see: http://www.linux-mm.org/ .\n"
- "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
+  Kirill A. Shutemov
 
-11a532e61d1004bc9f287d440d0378a80b6ac7312aee467582579b9cfe0e4303
+38b54409f77097d8e60ff7593777a4b500bdd287816b113cde170dc66c604079

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.