On Fri, Jan 19, 2018 at 7:11 AM, Michal Hocko [off-list ref] wrote:

On Fri 19-01-18 06:49:29, Shakeel Butt wrote:

quoted

On Fri, Jan 19, 2018 at 5:35 AM, Michal Hocko [off-list ref] wrote:

quoted

On Fri 19-01-18 16:25:44, Andrey Ryabinin wrote:

quoted

Currently mem_cgroup_resize_limit() retries to set limit after reclaiming
32 pages. It makes more sense to reclaim needed amount of pages right away.

This works noticeably faster, especially if 'usage - limit' big.
E.g. bringing down limit from 4G to 50M:

Before:
 # perf stat echo 50M > memory.limit_in_bytes

     Performance counter stats for 'echo 50M':

            386.582382      task-clock (msec)         #    0.835 CPUs utilized
                 2,502      context-switches          #    0.006 M/sec

           0.463244382 seconds time elapsed

After:
 # perf stat echo 50M > memory.limit_in_bytes

     Performance counter stats for 'echo 50M':

            169.403906      task-clock (msec)         #    0.849 CPUs utilized
                    14      context-switches          #    0.083 K/sec

           0.199536900 seconds time elapsed

But I am not going ack this one. As already stated this has a risk
of over-reclaim if there a lot of charges are freed along with this
shrinking. This is more of a theoretical concern so I am _not_ going to

If you don't mind, can you explain why over-reclaim is a concern at
all? The only side effect of over reclaim I can think of is the job
might suffer a bit over (more swapins & pageins). Shouldn't this be
within the expectation of the user decreasing the limits?

It is not a disaster. But it is an unexpected side effect of the
implementation. If you have limit 1GB and want to reduce it 500MB
then it would be quite surprising to land at 200M just because somebody
was freeing 300MB in parallel. Is this likely? Probably not but the more
is the limit touched and the larger are the differences the more likely
it is. Keep retrying in the smaller amounts and you will not see the
above happening.

And to be honest, I do not really see why keeping retrying from
mem_cgroup_resize_limit should be so much faster than keep retrying from
the direct reclaim path. We are doing SWAP_CLUSTER_MAX batches anyway.
mem_cgroup_resize_limit loop adds _some_ overhead but I am not really
sure why it should be that large.

Thanks for the explanation. Another query, we do not call
drain_all_stock() in mem_cgroup_resize_limit() but memory_max_write()
does call drain_all_stock(). Was this intentional or missed
accidentally?

--
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>