All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20181106052833.GC6203@intel.com>

diff --git a/a/1.txt b/N1/1.txt
index fd6f9e0..977ff63 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,7 +3,7 @@ Buddy. This is OK for high order page, but for order-0 pages, it
 misses the optimization opportunity of using Per-Cpu-Pages and can
 cause zone lock contention when called frequently.
 
-PaweA? Staszewski recently shared his result of 'how Linux kernel
+Paweł Staszewski recently shared his result of 'how Linux kernel
 handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer
 found the lock contention comes from page allocator:
 
@@ -45,7 +45,7 @@ Fix this by doing similar things as in __page_frag_cache_drain() -
 send the being freed page to PCP if it's an order-0 page, or
 directly to Buddy if it is a high order page.
 
-With this change, PaweA? hasn't noticed lock contention yet in
+With this change, Paweł hasn't noticed lock contention yet in
 his workload and Jesper has noticed a 7% performance improvement
 using a micro benchmark and lock contention is gone. Ilias' test
 on a 'low' speed 1Gbit interface on an cortex-a53 shows ~11%
@@ -55,7 +55,7 @@ disappeared from perf top.
 [1]: https://www.spinics.net/lists/netdev/msg531362.html
 [2]: https://www.spinics.net/lists/netdev/msg531421.html
 [3]: https://www.spinics.net/lists/netdev/msg531556.html
-Reported-by: PaweA? Staszewski <pstaszewski@itcare.pl>
+Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
 Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>
 Acked-by: Vlastimil Babka <vbabka@suse.cz>
 Acked-by: Mel Gorman <mgorman@techsingularity.net>
diff --git a/a/content_digest b/N1/content_digest
index 56979f5..e8eeef1 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -25,7 +25,7 @@
  "misses the optimization opportunity of using Per-Cpu-Pages and can\n"
  "cause zone lock contention when called frequently.\n"
  "\n"
- "PaweA? Staszewski recently shared his result of 'how Linux kernel\n"
+ "Pawe\305\202 Staszewski recently shared his result of 'how Linux kernel\n"
  "handles normal traffic'[1] and from perf data, Jesper Dangaard Brouer\n"
  "found the lock contention comes from page allocator:\n"
  "\n"
@@ -67,7 +67,7 @@
  "send the being freed page to PCP if it's an order-0 page, or\n"
  "directly to Buddy if it is a high order page.\n"
  "\n"
- "With this change, PaweA? hasn't noticed lock contention yet in\n"
+ "With this change, Pawe\305\202 hasn't noticed lock contention yet in\n"
  "his workload and Jesper has noticed a 7% performance improvement\n"
  "using a micro benchmark and lock contention is gone. Ilias' test\n"
  "on a 'low' speed 1Gbit interface on an cortex-a53 shows ~11%\n"
@@ -77,7 +77,7 @@
  "[1]: https://www.spinics.net/lists/netdev/msg531362.html\n"
  "[2]: https://www.spinics.net/lists/netdev/msg531421.html\n"
  "[3]: https://www.spinics.net/lists/netdev/msg531556.html\n"
- "Reported-by: PaweA? Staszewski <pstaszewski@itcare.pl>\n"
+ "Reported-by: Pawe\305\202 Staszewski <pstaszewski@itcare.pl>\n"
  "Analysed-by: Jesper Dangaard Brouer <brouer@redhat.com>\n"
  "Acked-by: Vlastimil Babka <vbabka@suse.cz>\n"
  "Acked-by: Mel Gorman <mgorman@techsingularity.net>\n"
@@ -119,4 +119,4 @@
  "-- \n"
  2.17.2
 
-de84c707f65a4e6820e82e5c71d6db5034ccb9a4c3430447832f9b78107dd7db
+f926531369ed4c759a8b750fa775d14a700fde0a5bee8a565b8ef319b30eccd3

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.