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

diff --git a/a/1.txt b/N1/1.txt
index 6f4e739..dce70d7 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -24,13 +24,13 @@ On Wed, 2017-03-15 at 17:28 +0100, Michal Hocko wrote:
 
 >From Aaron's data, it seems like 4 is a reasonable value for max_active:
 
-max_active:A A A time
-1A A A A A A A A A A A A A 8.9sA A A A+-0.5%
-2A A A A A A A A A A A A A 5.65sA A A+-5.5%
-4A A A A A A A A A A A A A 4.84sA A A+-0.16%
-8A A A A A A A A A A A A A 4.77sA A A+-0.97%
-16A A A A A A A A A A A A 4.85sA A A+-0.77%
-32A A A A A A A A A A A A 6.21sA A A+-0.46%
+max_active:   time
+1             8.9s   ±0.5%
+2             5.65s  ±5.5%
+4             4.84s  ±0.16%
+8             4.77s  ±0.97%
+16            4.85s  ±0.77%
+32            6.21s  ±0.46%
 
 
 > Moreover, and this is a more generic question, is this functionality
@@ -42,7 +42,7 @@ should help start the next job sooner.
 > After all the amount of the work to
 > be done is the same we just risk more lock contentions, unexpected CPU
 > usage etc. Which workloads will benefit from having exit path faster?
-> A 
+>  
 > > 
 > > > 
 > > > if we offload the page freeing to the worker then the original context
@@ -62,16 +62,10 @@ should help start the next job sooner.
 You do have a point that this page freeing activities should strive to
 affect other threads not in the same cgroup minimally.
 
-On the other hand, we also don't do this throttling of kworkersA 
+On the other hand, we also don't do this throttling of kworkers 
 today (e.g. pdflush) according to the cgroup it is doing work for.
 
 
 Thanks.
 
 Tim
-
---
-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 c83ef1c..a5c0f8d 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -41,13 +41,13 @@
  "\n"
  ">From Aaron's data, it seems like 4 is a reasonable value for max_active:\n"
  "\n"
- "max_active:A A A time\n"
- "1A A A A A A A A A A A A A 8.9sA A A A+-0.5%\n"
- "2A A A A A A A A A A A A A 5.65sA A A+-5.5%\n"
- "4A A A A A A A A A A A A A 4.84sA A A+-0.16%\n"
- "8A A A A A A A A A A A A A 4.77sA A A+-0.97%\n"
- "16A A A A A A A A A A A A 4.85sA A A+-0.77%\n"
- "32A A A A A A A A A A A A 6.21sA A A+-0.46%\n"
+ "max_active:\302\240\302\240\302\240time\n"
+ "1\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2408.9s\302\240\302\240\302\240\302\2610.5%\n"
+ "2\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2405.65s\302\240\302\240\302\2615.5%\n"
+ "4\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2404.84s\302\240\302\240\302\2610.16%\n"
+ "8\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2404.77s\302\240\302\240\302\2610.97%\n"
+ "16\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2404.85s\302\240\302\240\302\2610.77%\n"
+ "32\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\2406.21s\302\240\302\240\302\2610.46%\n"
  "\n"
  "\n"
  "> Moreover, and this is a more generic question, is this functionality\n"
@@ -59,7 +59,7 @@
  "> After all the amount of the work to\n"
  "> be done is the same we just risk more lock contentions, unexpected CPU\n"
  "> usage etc. Which workloads will benefit from having exit path faster?\n"
- "> A \n"
+ "> \302\240\n"
  "> > \n"
  "> > > \n"
  "> > > if we offload the page freeing to the worker then the original context\n"
@@ -79,18 +79,12 @@
  "You do have a point that this page freeing activities should strive to\n"
  "affect other threads not in the same cgroup minimally.\n"
  "\n"
- "On the other hand, we also don't do this throttling of kworkersA \n"
+ "On the other hand, we also don't do this throttling of kworkers\302\240\n"
  "today (e.g. pdflush) according to the cgroup it is doing work for.\n"
  "\n"
  "\n"
  "Thanks.\n"
  "\n"
- "Tim\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>"
+ Tim
 
-8a6485abefdba63702a9bad49501741bf045c29b3fd8aff9f62749346142fe49
+0287a6cc46f98557e8877af919e2d8264cd53747933b7de66e4d0efb4e7d9b5f

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.