All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20110608204218.GG1150@redhat.com>

diff --git a/a/1.txt b/N1/1.txt
index bdc125d..b325ab7 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -116,10 +116,3 @@ I guess in common case people will use a common dirty ratio for all cgroups
 
 Thanks
 Vivek
-
---
-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/ .
-Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
-Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N1/content_digest
index f16f0b8..126e3e6 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -144,13 +144,6 @@
  "(same as system dirty ratio). So it might not be of much value.\n"
  "\n"
  "Thanks\n"
- "Vivek\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"
- "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n"
- "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
+ Vivek
 
-103685b6e2998f9f362101a16594bfe5c80c4cd37d682fb35ff7b7e01b44dd33
+f88869c54de90f9bf6131d2a80e258e08dc7471a571dd31839cd0c2ee5ef0faf

diff --git a/a/1.txt b/N2/1.txt
index bdc125d..691703d 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -19,24 +19,24 @@ On Wed, Jun 08, 2011 at 01:03:15PM +0900, KAMEZAWA Hiroyuki wrote:
 > > >> > > [..]
 > > >> > >> -static inline bool over_bground_thresh(void)
 > > >> > >> +static inline bool over_bground_thresh(struct bdi_writeback *wb,
-> > >> > >> +                                       struct writeback_control *wbc)
-> > >> > >>  {
-> > >> > >>          unsigned long background_thresh, dirty_thresh;
+> > >> > >> +                                       struct writeback_control *wbc)
+> > >> > >>  {
+> > >> > >>          unsigned long background_thresh, dirty_thresh;
 > > >> > >>
-> > >> > >>          global_dirty_limits(&background_thresh, &dirty_thresh);
+> > >> > >>          global_dirty_limits(&background_thresh, &dirty_thresh);
 > > >> > >>
-> > >> > >> -        return (global_page_state(NR_FILE_DIRTY) +
-> > >> > >> -                global_page_state(NR_UNSTABLE_NFS) > background_thresh);
-> > >> > >> +        if (global_page_state(NR_FILE_DIRTY) +
-> > >> > >> +            global_page_state(NR_UNSTABLE_NFS) > background_thresh) {
-> > >> > >> +                wbc->for_cgroup = 0;
-> > >> > >> +                return true;
-> > >> > >> +        }
+> > >> > >> -        return (global_page_state(NR_FILE_DIRTY) +
+> > >> > >> -                global_page_state(NR_UNSTABLE_NFS) > background_thresh);
+> > >> > >> +        if (global_page_state(NR_FILE_DIRTY) +
+> > >> > >> +            global_page_state(NR_UNSTABLE_NFS) > background_thresh) {
+> > >> > >> +                wbc->for_cgroup = 0;
+> > >> > >> +                return true;
+> > >> > >> +        }
 > > >> > >> +
-> > >> > >> +        wbc->for_cgroup = 1;
-> > >> > >> +        wbc->shared_inodes = 1;
-> > >> > >> +        return mem_cgroups_over_bground_dirty_thresh();
-> > >> > >>  }
+> > >> > >> +        wbc->for_cgroup = 1;
+> > >> > >> +        wbc->shared_inodes = 1;
+> > >> > >> +        return mem_cgroups_over_bground_dirty_thresh();
+> > >> > >>  }
 > > >> > >
 > > >> > > Hi Greg,
 > > >> > >
@@ -44,10 +44,10 @@ On Wed, Jun 08, 2011 at 01:03:15PM +0900, KAMEZAWA Hiroyuki wrote:
 > > >> > > below background limit. The moment we cross background limit, looks
 > > >> > > like we will fall back to existing way of writting inodes?
 > > >> >
-> > >> > Correct.  If the system is over its background limit then the previous
-> > >> > cgroup-unaware background writeback occurs.  I think of the system
-> > >> > limits as those of the root cgroup.  If the system is over the global
-> > >> > limit than all cgroups are eligible for writeback.  In this situation
+> > >> > Correct.  If the system is over its background limit then the previous
+> > >> > cgroup-unaware background writeback occurs.  I think of the system
+> > >> > limits as those of the root cgroup.  If the system is over the global
+> > >> > limit than all cgroups are eligible for writeback.  In this situation
 > > >> > the current code does not distinguish between cgroups over or under
 > > >> > their dirty background limit.
 > > >> >
@@ -65,9 +65,9 @@ On Wed, Jun 08, 2011 at 01:03:15PM +0900, KAMEZAWA Hiroyuki wrote:
 > > >> > It might make more sense to reverse the order of the checks in the
 > > >> > proposed over_bground_thresh(): the new version would first check if any
 > > >> > memcg are over limit; assuming none are over limit, then check global
-> > >> > limits.  Assuming that the system is over its background limit and some
+> > >> > limits.  Assuming that the system is over its background limit and some
 > > >> > cgroups are also over their limits, then the over limit cgroups would
-> > >> > first be written possibly getting the system below its limit.  Does this
+> > >> > first be written possibly getting the system below its limit.  Does this
 > > >> > address your concern?
 > > >>
 > > >> Do you treat root group also as any other cgroup? If no, then above logic
diff --git a/a/content_digest b/N2/content_digest
index f16f0b8..430daf1 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -48,24 +48,24 @@
  "> > >> > > [..]\n"
  "> > >> > >> -static inline bool over_bground_thresh(void)\n"
  "> > >> > >> +static inline bool over_bground_thresh(struct bdi_writeback *wb,\n"
- "> > >> > >> + \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\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 struct writeback_control *wbc)\n"
- "> > >> > >> \302\240{\n"
- "> > >> > >> \302\240 \302\240 \302\240 \302\240 \302\240unsigned long background_thresh, dirty_thresh;\n"
+ "> > >> > >> +                                       struct writeback_control *wbc)\n"
+ "> > >> > >>  {\n"
+ "> > >> > >>          unsigned long background_thresh, dirty_thresh;\n"
  "> > >> > >>\n"
- "> > >> > >> \302\240 \302\240 \302\240 \302\240 \302\240global_dirty_limits(&background_thresh, &dirty_thresh);\n"
+ "> > >> > >>          global_dirty_limits(&background_thresh, &dirty_thresh);\n"
  "> > >> > >>\n"
- "> > >> > >> - \302\240 \302\240 \302\240 \302\240return (global_page_state(NR_FILE_DIRTY) +\n"
- "> > >> > >> - \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240global_page_state(NR_UNSTABLE_NFS) > background_thresh);\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240if (global_page_state(NR_FILE_DIRTY) +\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240global_page_state(NR_UNSTABLE_NFS) > background_thresh) {\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240wbc->for_cgroup = 0;\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240return true;\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240}\n"
+ "> > >> > >> -        return (global_page_state(NR_FILE_DIRTY) +\n"
+ "> > >> > >> -                global_page_state(NR_UNSTABLE_NFS) > background_thresh);\n"
+ "> > >> > >> +        if (global_page_state(NR_FILE_DIRTY) +\n"
+ "> > >> > >> +            global_page_state(NR_UNSTABLE_NFS) > background_thresh) {\n"
+ "> > >> > >> +                wbc->for_cgroup = 0;\n"
+ "> > >> > >> +                return true;\n"
+ "> > >> > >> +        }\n"
  "> > >> > >> +\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240wbc->for_cgroup = 1;\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240wbc->shared_inodes = 1;\n"
- "> > >> > >> + \302\240 \302\240 \302\240 \302\240return mem_cgroups_over_bground_dirty_thresh();\n"
- "> > >> > >> \302\240}\n"
+ "> > >> > >> +        wbc->for_cgroup = 1;\n"
+ "> > >> > >> +        wbc->shared_inodes = 1;\n"
+ "> > >> > >> +        return mem_cgroups_over_bground_dirty_thresh();\n"
+ "> > >> > >>  }\n"
  "> > >> > >\n"
  "> > >> > > Hi Greg,\n"
  "> > >> > >\n"
@@ -73,10 +73,10 @@
  "> > >> > > below background limit. The moment we cross background limit, looks\n"
  "> > >> > > like we will fall back to existing way of writting inodes?\n"
  "> > >> >\n"
- "> > >> > Correct. \302\240If the system is over its background limit then the previous\n"
- "> > >> > cgroup-unaware background writeback occurs. \302\240I think of the system\n"
- "> > >> > limits as those of the root cgroup. \302\240If the system is over the global\n"
- "> > >> > limit than all cgroups are eligible for writeback. \302\240In this situation\n"
+ "> > >> > Correct.  If the system is over its background limit then the previous\n"
+ "> > >> > cgroup-unaware background writeback occurs.  I think of the system\n"
+ "> > >> > limits as those of the root cgroup.  If the system is over the global\n"
+ "> > >> > limit than all cgroups are eligible for writeback.  In this situation\n"
  "> > >> > the current code does not distinguish between cgroups over or under\n"
  "> > >> > their dirty background limit.\n"
  "> > >> >\n"
@@ -94,9 +94,9 @@
  "> > >> > It might make more sense to reverse the order of the checks in the\n"
  "> > >> > proposed over_bground_thresh(): the new version would first check if any\n"
  "> > >> > memcg are over limit; assuming none are over limit, then check global\n"
- "> > >> > limits. \302\240Assuming that the system is over its background limit and some\n"
+ "> > >> > limits.  Assuming that the system is over its background limit and some\n"
  "> > >> > cgroups are also over their limits, then the over limit cgroups would\n"
- "> > >> > first be written possibly getting the system below its limit. \302\240Does this\n"
+ "> > >> > first be written possibly getting the system below its limit.  Does this\n"
  "> > >> > address your concern?\n"
  "> > >>\n"
  "> > >> Do you treat root group also as any other cgroup? If no, then above logic\n"
@@ -153,4 +153,4 @@
  "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n"
  "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-103685b6e2998f9f362101a16594bfe5c80c4cd37d682fb35ff7b7e01b44dd33
+279338ada76b35e6b305b1e94e8b0ec512180536c6901baf6cb501c8be37d998

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.