All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20170810042040.GA2249@bbox>

diff --git a/a/content_digest b/N1/content_digest
index b171b70..3a21827 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,31 +1,9 @@
- "ref\020170802000818.4760-7-namit@vmware.com\0"
- "ref\020170808011923.GE25554@yexl-desktop\0"
- "ref\020170808022830.GA28570@bbox\0"
- "ref\093CA4B47-95C2-43A2-8E92-B142CAB1DAF7@gmail.com\0"
- "ref\0970B5DC5-BFC2-461E-AC46-F71B3691D301@gmail.com\0"
- "ref\020170808080821.GA31730@bbox\0"
- "ref\020170809025902.GA17616@yexl-desktop\0"
- "ref\020170810041353.GB2042@bbox\0"
  "ref\080589593-6F0E-4421-9279-681D5B388100@gmail.com\0"
  "From\0Minchan Kim <minchan@kernel.org>\0"
- "Subject\0Re: [lkp-robot] [mm]  7674270022:  will-it-scale.per_process_ops -19.3% regression\0"
+ "Subject\0Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression\0"
  "Date\0Thu, 10 Aug 2017 13:20:40 +0900\0"
- "To\0Nadav Amit <nadav.amit@gmail.com>\0"
- "Cc\0Ye Xiaolong <xiaolong.ye@intel.com>"
-  open list:MEMORY MANAGEMENT <linux-mm@kvack.org>
-  LKML <linux-kernel@vger.kernel.org>
-  Andrew Morton <akpm@linux-foundation.org>
-  Ingo Molnar <mingo@redhat.com>
-  Russell King <linux@armlinux.org.uk>
-  Tony Luck <tony.luck@intel.com>
-  Martin Schwidefsky <schwidefsky@de.ibm.com>
-  David S. Miller <davem@davemloft.net>
-  Heiko Carstens <heiko.carstens@de.ibm.com>
-  Yoshinori Sato <ysato@users.sourceforge.jp>
-  Jeff Dike <jdike@addtoit.com>
-  linux-arch@vger.kernel.org
- " lkp@01.org\0"
- "\00:1\0"
+ "To\0lkp@lists.01.org\0"
+ "\01:1\0"
  "b\0"
  "On Wed, Aug 09, 2017 at 09:14:50PM -0700, Nadav Amit wrote:\n"
  "\n"
@@ -76,4 +54,4 @@
  "Never mind! It always happens. :)\n"
  In this chance, I really appreciates your insight/testing/cooperation!
 
-c5e46a1cc8b105b7b0d4dc2f92d3119c12f8c44c1ee9e9117974712f3118b7f4
+1eb45a9137e044c7ec5f0242cfe91932d77ba0918c52d5c8012c2160fa686937

diff --git a/a/1.txt b/N2/1.txt
index 458f70d..c54172d 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -5,13 +5,13 @@ Hi Nadav,
 < snip >
 
 > >>>>> According to the description it is "testcase:brk increase/decrease of one
-> >>>>> page”. According to the mode it spawns multiple processes, not threads.
+> >>>>> pagea??. According to the mode it spawns multiple processes, not threads.
 > >>>>> 
 > >>>>> Since a single page is unmapped each time, and the iTLB-loads increase
 > >>>>> dramatically, I would suspect that for some reason a full TLB flush is
 > >>>>> caused during do_munmap().
 > >>>>> 
-> >>>>> If I find some free time, I’ll try to profile the workload - but feel free
+> >>>>> If I find some free time, Ia??ll try to profile the workload - but feel free
 > >>>>> to beat me to it.
 > >>>> 
 > >>>> The root-cause appears to be that tlb_finish_mmu() does not call
@@ -32,10 +32,10 @@ Hi Nadav,
 > >>         %stddev      change         %stddev      change         %stddev
 > >>             \          |                \          |                \  
 > >>   3405093             -19%    2747088              -2%    3348752        will-it-scale.per_process_ops
-> >>      1280 ±  3%        -2%       1257 ±  3%        -6%       1207        vmstat.system.cs
-> >>      2702 ± 18%        11%       3002 ± 19%        17%       3156 ± 18%  numa-vmstat.node0.nr_mapped
-> >>     10765 ± 18%        11%      11964 ± 19%        17%      12588 ± 18%  numa-meminfo.node0.Mapped
-> >>      0.00 ± 47%       -40%       0.00 ± 45%       -84%       0.00 ± 42%  mpstat.cpu.soft%
+> >>      1280 A+-  3%        -2%       1257 A+-  3%        -6%       1207        vmstat.system.cs
+> >>      2702 A+- 18%        11%       3002 A+- 19%        17%       3156 A+- 18%  numa-vmstat.node0.nr_mapped
+> >>     10765 A+- 18%        11%      11964 A+- 19%        17%      12588 A+- 18%  numa-meminfo.node0.Mapped
+> >>      0.00 A+- 47%       -40%       0.00 A+- 45%       -84%       0.00 A+- 42%  mpstat.cpu.soft%
 > >> 
 > >> Thanks,
 > >> Xiaolong
@@ -46,3 +46,9 @@ Hi Nadav,
 
 Never mind! It always happens. :)
 In this chance, I really appreciates your insight/testing/cooperation!
+
+--
+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/N2/content_digest
index b171b70..94ebec3 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -34,13 +34,13 @@
  "< snip >\n"
  "\n"
  "> >>>>> According to the description it is \"testcase:brk increase/decrease of one\n"
- "> >>>>> page\342\200\235. According to the mode it spawns multiple processes, not threads.\n"
+ "> >>>>> pagea??. According to the mode it spawns multiple processes, not threads.\n"
  "> >>>>> \n"
  "> >>>>> Since a single page is unmapped each time, and the iTLB-loads increase\n"
  "> >>>>> dramatically, I would suspect that for some reason a full TLB flush is\n"
  "> >>>>> caused during do_munmap().\n"
  "> >>>>> \n"
- "> >>>>> If I find some free time, I\342\200\231ll try to profile the workload - but feel free\n"
+ "> >>>>> If I find some free time, Ia??ll try to profile the workload - but feel free\n"
  "> >>>>> to beat me to it.\n"
  "> >>>> \n"
  "> >>>> The root-cause appears to be that tlb_finish_mmu() does not call\n"
@@ -61,10 +61,10 @@
  "> >>         %stddev      change         %stddev      change         %stddev\n"
  "> >>             \\          |                \\          |                \\  \n"
  "> >>   3405093             -19%    2747088              -2%    3348752        will-it-scale.per_process_ops\n"
- "> >>      1280 \302\261  3%        -2%       1257 \302\261  3%        -6%       1207        vmstat.system.cs\n"
- "> >>      2702 \302\261 18%        11%       3002 \302\261 19%        17%       3156 \302\261 18%  numa-vmstat.node0.nr_mapped\n"
- "> >>     10765 \302\261 18%        11%      11964 \302\261 19%        17%      12588 \302\261 18%  numa-meminfo.node0.Mapped\n"
- "> >>      0.00 \302\261 47%       -40%       0.00 \302\261 45%       -84%       0.00 \302\261 42%  mpstat.cpu.soft%\n"
+ "> >>      1280 A+-  3%        -2%       1257 A+-  3%        -6%       1207        vmstat.system.cs\n"
+ "> >>      2702 A+- 18%        11%       3002 A+- 19%        17%       3156 A+- 18%  numa-vmstat.node0.nr_mapped\n"
+ "> >>     10765 A+- 18%        11%      11964 A+- 19%        17%      12588 A+- 18%  numa-meminfo.node0.Mapped\n"
+ "> >>      0.00 A+- 47%       -40%       0.00 A+- 45%       -84%       0.00 A+- 42%  mpstat.cpu.soft%\n"
  "> >> \n"
  "> >> Thanks,\n"
  "> >> Xiaolong\n"
@@ -74,6 +74,12 @@
  "> Sorry again for screwing your patch, Minchan.\n"
  "\n"
  "Never mind! It always happens. :)\n"
- In this chance, I really appreciates your insight/testing/cooperation!
+ "In this chance, I really appreciates your insight/testing/cooperation!\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>"
 
-c5e46a1cc8b105b7b0d4dc2f92d3119c12f8c44c1ee9e9117974712f3118b7f4
+322b8cabc6b852c5540bbb2c6841fde8347f017f86d33e511c54ab33835b9742

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.