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. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
