memcg: skip scanning active lists based on individual size

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

Quoted 20 lines · Johannes Weiner

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Quoted 6 lines

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

Reviewed-by Minchan Kim <[email protected]>

I can't understand why memcg is designed for considering all nodes and zones. Is it a mistake or on purpose?
Maybe Kame or Balbir can answer it.

Anyway, this change does make sense to me.

Nitpick: Please remove inactive_ratio in Documentation/cgroups/memory.txt. I think it would be better to separate it into another patch.

Quoted 20 lines · Johannes Weiner

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Quoted 6 lines

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

Reviewed-by Minchan Kim <[email protected]>

I can't understand why memcg is designed for considering all nodes and zones. Is it a mistake or on purpose?

Quoted 28 lines · On Wed, 31 Aug 2011 19:13:34 +0900 Minchan Kim <[email protected]> wrote:

Quoted 26 lines · Johannes Weiner

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

Quoted 4 lines

Reviewed-by Minchan Kim <[email protected]>

I can't understand why memcg is designed for considering all nodes and zones. Is it a mistake or on purpose?

It's purpose. memcg just takes care of the amount of pages.

But, hmm, this change may be good for softlimit and your work.

I'll ack when you add performance numbers in changelog.

Quoted 33 lines · KAMEZAWA Hiroyuki

Quoted 30 lines · On Wed, 31 Aug 2011 19:13:34 +0900 Minchan Kim <[email protected]> wrote:

Quoted 20 lines · Johannes Weiner

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Quoted 6 lines

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

Reviewed-by Minchan Kim <[email protected]>

Quoted 4 lines

Quoted 2 lines

I can't understand why memcg is designed for considering all nodes and zones. Is it a mistake or on purpose?

It's purpose. memcg just takes care of the amount of pages.

This mechanism isn't about memcg at all, it's an aging decision at a much lower level. Can you tell me how the old implementation is supposed to work?

Quoted 1 line

But, hmm, this change may be good for softlimit and your work.

Yes, I noticed those paths showing up in a profile with my patches. Lots of memcgs on a multi-node machine will trigger it too. But it's secondary, my primary reasoning was: this does not make sense at all.

Quoted 1 line

I'll ack when you add performance numbers in changelog.

It's not exactly a performance optimization but I'll happily run some workloads. Do you have suggestions what to test for? I.e. where would you expect regressions?

Quoted 34 lines · On Thu, 1 Sep 2011 08:15:40 +0200 Johannes Weiner <[email protected]> wrote:

Quoted 33 lines · KAMEZAWA Hiroyuki

Quoted 30 lines · On Wed, 31 Aug 2011 19:13:34 +0900 Minchan Kim <[email protected]> wrote:

Quoted 20 lines · Johannes Weiner

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Quoted 6 lines

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

Reviewed-by Minchan Kim <[email protected]>

Quoted 9 lines

Quoted 4 lines

Quoted 2 lines

I can't understand why memcg is designed for considering all nodes and zones. Is it a mistake or on purpose?

It's purpose. memcg just takes care of the amount of pages.

This mechanism isn't about memcg at all, it's an aging decision at a much lower level. Can you tell me how the old implementation is supposed to work?

Old implemenation was supporsed to make vmscan to see only memcg and ignore zones. memcg doesn't take care of any zones. Then, it uses global numbers rather than zones.

Assume a system with 2 nodes and the whole memcg's inactive/active ratio is unbalaned.

   Node      0     1
   Active   800M   30M
   Inactive 100M   200M

If we judge 'unbalance' based on zones, Node1's Active will not rotate even if it's not accessed for a while.
If we judge unbalance based on total stat, Both of Node0 and Node 1 will be rotated.

Hmm, old one doesn't work as I expexted ?

But okay, as time goes, I think Node1's inactive will decreased and then, rotate will happen even with zone based ones.

Quoted 5 lines

Quoted 1 line

But, hmm, this change may be good for softlimit and your work.

Yes, I noticed those paths showing up in a profile with my patches. Lots of memcgs on a multi-node machine will trigger it too. But it's secondary, my primary reasoning was: this does not make sense at all.

your word sounds always too strong to me ;) please be soft.

Quoted 6 lines

Quoted 1 line

I'll ack when you add performance numbers in changelog.

It's not exactly a performance optimization but I'll happily run some workloads. Do you have suggestions what to test for? I.e. where would you expect regressions?

Some comparison about amount of swap-out before/after change will be good.

Hm. If I do...
- set up x86-64 NUMA box. (fake numa is ok.)
- create memcg with 500M limit.
- running kernel make with make -j 6(or more)

see time of make and amount of swap-out.

Quoted 13 lines · KAMEZAWA Hiroyuki

On Thu, 1 Sep 2011 08:15:40 +0200
Johannes Weiner <[email protected]> wrote:
Old implemenation was supporsed to make vmscan to see only memcg and ignore zones. memcg doesn't take care of any zones. Then, it uses global numbers rather than zones.

Assume a system with 2 nodes and the whole memcg's inactive/active ratio is unbalaned.

   Node      0     1
   Active   800M   30M
   Inactive 100M   200M

Quoted 4 lines

If we judge 'unbalance' based on zones, Node1's Active will not rotate even if it's not accessed for a while.
If we judge unbalance based on total stat, Both of Node0 and Node 1 will be rotated.

But why should we deactivate on Node 1? We have good reasons not to on the global level, why should memcgs silently behave differently?

I mostly don't understand it on a semantic level. vmscan needs to know whether a certain inactive LRU list has enough reclaim candidates to skip scanning its corresponding active list. The global state is not useful to find out if a single inactive list has enough pages.

Quoted 4 lines

Hmm, old one doesn't work as I expexted ?

But okay, as time goes, I think Node1's inactive will decreased and then, rotate will happen even with zone based ones.

Yes, that's how the mechanism is intended to work: with a constant influx of used-once pages, we don't want to touch the active list. But when the workload changes and inactive pages get either activated or all reclaimed, the ratio changes and eventually we fall back to deactivating pages again.

That's reclaim behaviour that has been around for a while and it shouldn't make a difference if your workload is running in root_mem_cgroup or another memcg.

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

But, hmm, this change may be good for softlimit and your work.

Yes, I noticed those paths showing up in a profile with my patches. Lots of memcgs on a multi-node machine will trigger it too. But it's secondary, my primary reasoning was: this does not make sense at all.

your word sounds always too strong to me ;) please be soft.

Sorry, I'll try to be less harsh. Please don't take it personally :)

What I meant was that the computational overhead was not the primary reason for this patch. Although a reduction there is very welcome, it's that deciding to skip the list based on the list size seems more correct than deciding based on the overall state of the memcg, which can only by accident show the same proportion of inactive/active.

It's a correctness fix for existing code, not an optimization or preparation for future changes.

Quoted 13 lines

Quoted 6 lines

Quoted 1 line

I'll ack when you add performance numbers in changelog.

It's not exactly a performance optimization but I'll happily run some workloads. Do you have suggestions what to test for? I.e. where would you expect regressions?

Some comparison about amount of swap-out before/after change will be good.

Hm. If I do...
- set up x86-64 NUMA box. (fake numa is ok.)
- create memcg with 500M limit.
- running kernel make with make -j 6(or more)

Quoted 1 line

see time of make and amount of swap-out.

4G ram, 500M swap on SSD, numa=fake=16, 10 runs of make -j11 in 500M memcg, standard deviation in parens:

seconds pswpin pswpout
vanilla: 175.359(0.106) 6906.900(1779.135) 8913.200(1917.369)
patched: 176.144(0.243) 8581.500(1833.432) 10872.400(2124.104)

Quoted 19 lines · On Mon, 5 Sep 2011 20:25:14 +0200 Johannes Weiner <[email protected]> wrote:

Quoted 17 lines · KAMEZAWA Hiroyuki

On Thu, 1 Sep 2011 08:15:40 +0200
Johannes Weiner <[email protected]> wrote:
Old implemenation was supporsed to make vmscan to see only memcg and ignore zones. memcg doesn't take care of any zones. Then, it uses global numbers rather than zones.

Assume a system with 2 nodes and the whole memcg's inactive/active ratio is unbalaned.

   Node      0     1
   Active   800M   30M
   Inactive 100M   200M

If we judge 'unbalance' based on zones, Node1's Active will not rotate even if it's not accessed for a while.
If we judge unbalance based on total stat, Both of Node0 and Node 1 will be rotated.

Quoted 2 lines

But why should we deactivate on Node 1? We have good reasons not to on the global level, why should memcgs silently behave differently?

One reason was I thought that memcg should behave as to have one LRU list, which is not devided by zones and wanted to ignore zones as much as possible. Second reason was that I don't want to increase swap-out caused by memcg limit.

Quoted 4 lines

I mostly don't understand it on a semantic level. vmscan needs to know whether a certain inactive LRU list has enough reclaim candidates to skip scanning its corresponding active list. The global state is not useful to find out if a single inactive list has enough pages.

Ok, I agree to this. I should add other logic to do what I want. In my series,
- passing nodemask
- avoid overscan
- calculating node weight
These will allow me to see what I want.

Quoted 18 lines

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

I'll ack when you add performance numbers in changelog.

It's not exactly a performance optimization but I'll happily run some workloads. Do you have suggestions what to test for? I.e. where would you expect regressions?

Quoted 8 lines

Some comparison about amount of swap-out before/after change will be good.

Hm. If I do...
- set up x86-64 NUMA box. (fake numa is ok.)
- create memcg with 500M limit.
- running kernel make with make -j 6(or more)

see time of make and amount of swap-out.

4G ram, 500M swap on SSD, numa=fake=16, 10 runs of make -j11 in 500M memcg, standard deviation in parens:

Quoted 3 lines

seconds pswpin pswpout
vanilla: 175.359(0.106) 6906.900(1779.135) 8913.200(1917.369)
patched: 176.144(0.243) 8581.500(1833.432) 10872.400(2124.104)

Hmm. swapin/out seems increased. But hmm...stddev is large. Is this expected ? reason ?

Anyway, I don't want to disturb you more. Thanks.

Quoted 22 lines · KAMEZAWA Hiroyuki

Quoted 19 lines · On Mon, 5 Sep 2011 20:25:14 +0200 Johannes Weiner <[email protected]> wrote:

Quoted 17 lines · KAMEZAWA Hiroyuki

On Thu, 1 Sep 2011 08:15:40 +0200
Johannes Weiner <[email protected]> wrote:
Old implemenation was supporsed to make vmscan to see only memcg and ignore zones. memcg doesn't take care of any zones. Then, it uses global numbers rather than zones.

Assume a system with 2 nodes and the whole memcg's inactive/active ratio is unbalaned.

   Node      0     1
   Active   800M   30M
   Inactive 100M   200M

If we judge 'unbalance' based on zones, Node1's Active will not rotate even if it's not accessed for a while.
If we judge unbalance based on total stat, Both of Node0 and Node 1 will be rotated.

Quoted 7 lines

Quoted 2 lines

But why should we deactivate on Node 1? We have good reasons not to on the global level, why should memcgs silently behave differently?

One reason was I thought that memcg should behave as to have one LRU list, which is not devided by zones and wanted to ignore zones as much as possible. Second reason was that I don't want to increase swap-out caused by memcg limit.

You can think of it like this: if every active list is only balanced when its inactive counterpart is too small, then the memcg-wide proportion of inactive vs. active pages is as desired, too. So even after my change, the 'one big LRU' has the right inactive/active ratio.

On the other hand, the old way could allow for the memcg-level to have the right proportion and still thrash one workload that is bound to another node even though its inactive > active, but is overshadowed by inactive < active workloads on other nodes.

Quoted 11 lines

Quoted 4 lines

I mostly don't understand it on a semantic level. vmscan needs to know whether a certain inactive LRU list has enough reclaim candidates to skip scanning its corresponding active list. The global state is not useful to find out if a single inactive list has enough pages.

Ok, I agree to this. I should add other logic to do what I want. In my series,
- passing nodemask
- avoid overscan
- calculating node weight
These will allow me to see what I want.

What /do/ you want? :) I just don't see your concern. I mean, yes, no increased swapout, but in what concrete scenario could you suspect swapping to increase because of this change?

Quoted 18 lines

Quoted 18 lines

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

I'll ack when you add performance numbers in changelog.

It's not exactly a performance optimization but I'll happily run some workloads. Do you have suggestions what to test for? I.e. where would you expect regressions?

Quoted 8 lines

Some comparison about amount of swap-out before/after change will be good.

Hm. If I do...
- set up x86-64 NUMA box. (fake numa is ok.)
- create memcg with 500M limit.
- running kernel make with make -j 6(or more)

see time of make and amount of swap-out.

4G ram, 500M swap on SSD, numa=fake=16, 10 runs of make -j11 in 500M memcg, standard deviation in parens:

Quoted 6 lines

Quoted 3 lines

seconds pswpin pswpout
vanilla: 175.359(0.106) 6906.900(1779.135) 8913.200(1917.369)
patched: 176.144(0.243) 8581.500(1833.432) 10872.400(2124.104)

Hmm. swapin/out seems increased. But hmm...stddev is large. Is this expected ? reason ?

It's kind of expected because there is only a small number of parallel jobs that have bursty memory usage, so the slightest timing variations can make the difference between an episode of heavy thrashing and the tasks having their bursts at different times and getting along fine.

So we are basically looking at test results that are clustered around not one, but several different mean values. The arithmetic mean is not really meaningful for these samples.

Quoted 1 line

Anyway, I don't want to disturb you more. Thanks.

I am happy to test if my changes introduce regressions, I don't want that, obviously. But do you have a theory behind your concern that swapping could increase? Just saying, this test request seemed a bit random because I don't see where my change would affect this particular workload.

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Signed-off-by Johannes Weiner <[email protected]>

Cc Rik van Riel <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc KAMEZAWA Hiroyuki <[email protected]>

Cc Daisuke Nishimura <[email protected]>

Cc Balbir Singh <[email protected]>

---
 include/linux/memcontrol.h |   10 +++++---
 mm/memcontrol.c            |   51 ++++++++++++++----------------------------- mm/vmscan.c                |    4 +-

 3 files changed, 25 insertions(+), 40 deletions(-)

include/linux/memcontrol.h +4 -2

index 343bd76..cbb45ce 100644
@@ -105,8 +105,10 @@ extern void mem_cgroup_end_migration(struct mem_cgroup *mem,
  /*
  * For memory reclaim.
  */
-int mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg);
-int mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg);
+int mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg,
+                                   struct zone *zone);
+int mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg,
+                                   struct zone *zone);
  int mem_cgroup_select_victim_node(struct mem_cgroup *memcg);
  unsigned long mem_cgroup_zone_nr_lru_pages(struct mem_cgroup *memcg,
                                        int nid, int zid, unsigned int lrumask);

@@ -292,13 +294,13 @@ static inline bool mem_cgroup_disabled(void)
  }
 

 static inline int

include/linux/memcontrol.h +1 -1

-mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg)
+mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg, struct zone *zone)

 {
       return 1;
 }

 static inline int

include/linux/memcontrol.h +1 -1

-mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg)
+mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg, struct zone *zone)

 {
       return 1;
 }

mm/memcontrol.c +9 -5

index 3508777..d63dfb2 100644
@@ -1101,15 +1101,19 @@ int task_in_mem_cgroup(struct task_struct *task, const struct mem_cgroup *mem)
        return ret;
  }
 
-static int calc_inactive_ratio(struct mem_cgroup *memcg, unsigned long *present_pages)
+int mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg, struct zone *zone)
  {
-       unsigned long active;
+       unsigned long inactive_ratio;
+       int nid = zone_to_nid(zone);
+       int zid = zone_idx(zone);
        unsigned long inactive;
+       unsigned long active;
        unsigned long gb;
-       unsigned long inactive_ratio;
 
-       inactive = mem_cgroup_nr_lru_pages(memcg, BIT(LRU_INACTIVE_ANON));
-       active = mem_cgroup_nr_lru_pages(memcg, BIT(LRU_ACTIVE_ANON));
+       inactive = mem_cgroup_zone_nr_lru_pages(memcg, nid, zid,
+                                               BIT(LRU_INACTIVE_ANON));
+       active = mem_cgroup_zone_nr_lru_pages(memcg, nid, zid,
+                                             BIT(LRU_ACTIVE_ANON));
 
        gb = (inactive + active) >> (30 - PAGE_SHIFT);
        if (gb)

@@ -1117,39 +1121,20 @@ static int calc_inactive_ratio(struct mem_cgroup *memcg, unsigned long *present_

       else
               inactive_ratio = 1;

-       if (present_pages) {
-               present_pages[0] = inactive;
-               present_pages[1] = active;
-       }
-
-       return inactive_ratio;
+       return inactive * inactive_ratio < active; }

mm/memcontrol.c +1 -19

-int mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg)
-{
-       unsigned long active;
-       unsigned long inactive;
-       unsigned long present_pages[2];
-       unsigned long inactive_ratio;
-
-       inactive_ratio = calc_inactive_ratio(memcg, present_pages);
-
-       inactive = present_pages[0];
-       active = present_pages[1];
-
-       if (inactive * inactive_ratio < active)
-               return 1;
-
-       return 0;
-}
-
-int mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg)
+int mem_cgroup_inactive_file_is_low(struct mem_cgroup *memcg, struct zone *zone)

 {
       unsigned long active;
       unsigned long inactive;
+       int zid = zone_idx(zone);
+       int nid = zone_to_nid(zone);

-       inactive = mem_cgroup_nr_lru_pages(memcg, BIT(LRU_INACTIVE_FILE));
-       active = mem_cgroup_nr_lru_pages(memcg, BIT(LRU_ACTIVE_FILE));
+       inactive = mem_cgroup_zone_nr_lru_pages(memcg, nid, zid,
+                                               BIT(LRU_INACTIVE_FILE));
+       active = mem_cgroup_zone_nr_lru_pages(memcg, nid, zid,
+                                             BIT(LRU_ACTIVE_FILE));

       return (active > inactive);
 }

mm/memcontrol.c +0 -2

@@ -4188,8 +4173,6 @@ static int mem_control_stat_show(struct cgroup *cont, struct cftype *cft,
        }
 
  #ifdef CONFIG_DEBUG_VM
-       cb->fill(cb, "inactive_ratio", calc_inactive_ratio(mem_cont, NULL));
-
        {
                int nid, zid;
                struct mem_cgroup_per_zone *mz;

mm/vmscan.c +0 -0

index 6588746..a023778 100644
@@ -1699,7 +1699,7 @@ static int inactive_anon_is_low(struct zone *zone, struct scan_control *sc)
        if (scanning_global_lru(sc))
                low = inactive_anon_is_low_global(zone);

       else
-               low = mem_cgroup_inactive_anon_is_low(sc->mem_cgroup);
+               low = mem_cgroup_inactive_anon_is_low(sc->mem_cgroup, zone); return low;
 }
 #else

mm/vmscan.c +0 -0

@@ -1742,7 +1742,7 @@ static int inactive_file_is_low(struct zone *zone, struct scan_control *sc)
        if (scanning_global_lru(sc))
                low = inactive_file_is_low_global(zone);

       else
-               low = mem_cgroup_inactive_file_is_low(sc->mem_cgroup);
+               low = mem_cgroup_inactive_file_is_low(sc->mem_cgroup, zone); return low;
 }

--
1.7.6

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  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:"[email protected]"> [email protected] </a>

Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around.

The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones.

This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages.

Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned.

Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision.

Signed-off-by Johannes Weiner<[email protected]>

Cc Rik van Riel<[email protected]>

Cc KOSAKI Motohiro<[email protected]>

Cc KAMEZAWA Hiroyuki<[email protected]>

Cc Daisuke Nishimura<[email protected]>

Cc Balbir Singh<[email protected]>