On Fri, Jan 19, 2018 at 7:11 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Fri 19-01-18 06:49:29, Shakeel Butt wrote: >> On Fri, Jan 19, 2018 at 5:35 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: >> > On Fri 19-01-18 16:25:44, Andrey Ryabinin wrote: >> >> 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 from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
