From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755608AbeASOtl (ORCPT ); Fri, 19 Jan 2018 09:49:41 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:38896 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753570AbeASOtc (ORCPT ); Fri, 19 Jan 2018 09:49:32 -0500 X-Google-Smtp-Source: ACJfBotMgmVNfWGK6U9Cylj7bdUrCJXgMRyK0xvgu1cH4WKQ5ZSI/BzivimrxZVVdYqArIEWBGiYSuWCxgImdIvIHNs= MIME-Version: 1.0 In-Reply-To: <20180119133510.GD6584@dhcp22.suse.cz> References: <20171220102429.31601-1-aryabinin@virtuozzo.com> <20180119132544.19569-1-aryabinin@virtuozzo.com> <20180119132544.19569-2-aryabinin@virtuozzo.com> <20180119133510.GD6584@dhcp22.suse.cz> From: Shakeel Butt Date: Fri, 19 Jan 2018 06:49:29 -0800 Message-ID: Subject: Re: [PATCH v5 2/2] mm/memcontrol.c: Reduce reclaim retries in mem_cgroup_resize_limit() To: Michal Hocko Cc: Andrey Ryabinin , Andrew Morton , Cgroups , LKML , Linux MM , Johannes Weiner , Vladimir Davydov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 19, 2018 at 5:35 AM, Michal Hocko 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? > nack. If we ever see such a problem then reverting this patch should be > pretty straghtforward. > >> Signed-off-by: Andrey Ryabinin Reviewed-by: Shakeel Butt >> Cc: Shakeel Butt >> Cc: Michal Hocko >> Cc: Johannes Weiner >> Cc: Vladimir Davydov >> --- >> mm/memcontrol.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 9d987f3e79dc..09bac2df2f12 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2448,6 +2448,7 @@ static DEFINE_MUTEX(memcg_limit_mutex); >> static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> unsigned long limit, bool memsw) >> { >> + unsigned long nr_pages; >> bool enlarge = false; >> int ret; >> bool limits_invariant; >> @@ -2479,8 +2480,9 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> if (!ret) >> break; >> >> - if (!try_to_free_mem_cgroup_pages(memcg, 1, >> - GFP_KERNEL, !memsw)) { >> + nr_pages = max_t(long, 1, page_counter_read(counter) - limit); >> + if (!try_to_free_mem_cgroup_pages(memcg, nr_pages, >> + GFP_KERNEL, !memsw)) { >> ret = -EBUSY; >> break; >> } >> -- >> 2.13.6 >> >> -- >> 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: email@kvack.org > > -- > Michal Hocko > SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id A8C946B0038 for ; Fri, 19 Jan 2018 09:49:32 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id b186so3423739wmf.0 for ; Fri, 19 Jan 2018 06:49:32 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id c191sor374885wma.46.2018.01.19.06.49.31 for (Google Transport Security); Fri, 19 Jan 2018 06:49:31 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20180119133510.GD6584@dhcp22.suse.cz> References: <20171220102429.31601-1-aryabinin@virtuozzo.com> <20180119132544.19569-1-aryabinin@virtuozzo.com> <20180119132544.19569-2-aryabinin@virtuozzo.com> <20180119133510.GD6584@dhcp22.suse.cz> From: Shakeel Butt Date: Fri, 19 Jan 2018 06:49:29 -0800 Message-ID: Subject: Re: [PATCH v5 2/2] mm/memcontrol.c: Reduce reclaim retries in mem_cgroup_resize_limit() Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Andrey Ryabinin , Andrew Morton , Cgroups , LKML , Linux MM , Johannes Weiner , Vladimir Davydov On Fri, Jan 19, 2018 at 5:35 AM, Michal Hocko 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? > nack. If we ever see such a problem then reverting this patch should be > pretty straghtforward. > >> Signed-off-by: Andrey Ryabinin Reviewed-by: Shakeel Butt >> Cc: Shakeel Butt >> Cc: Michal Hocko >> Cc: Johannes Weiner >> Cc: Vladimir Davydov >> --- >> mm/memcontrol.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 9d987f3e79dc..09bac2df2f12 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2448,6 +2448,7 @@ static DEFINE_MUTEX(memcg_limit_mutex); >> static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> unsigned long limit, bool memsw) >> { >> + unsigned long nr_pages; >> bool enlarge = false; >> int ret; >> bool limits_invariant; >> @@ -2479,8 +2480,9 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> if (!ret) >> break; >> >> - if (!try_to_free_mem_cgroup_pages(memcg, 1, >> - GFP_KERNEL, !memsw)) { >> + nr_pages = max_t(long, 1, page_counter_read(counter) - limit); >> + if (!try_to_free_mem_cgroup_pages(memcg, nr_pages, >> + GFP_KERNEL, !memsw)) { >> ret = -EBUSY; >> break; >> } >> -- >> 2.13.6 >> >> -- >> 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: email@kvack.org > > -- > Michal Hocko > SUSE Labs -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shakeel Butt Subject: Re: [PATCH v5 2/2] mm/memcontrol.c: Reduce reclaim retries in mem_cgroup_resize_limit() Date: Fri, 19 Jan 2018 06:49:29 -0800 Message-ID: References: <20171220102429.31601-1-aryabinin@virtuozzo.com> <20180119132544.19569-1-aryabinin@virtuozzo.com> <20180119132544.19569-2-aryabinin@virtuozzo.com> <20180119133510.GD6584@dhcp22.suse.cz> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N02FebtAGD5vCCRdskBP/VH52MaejUNLu6vAU5z6CHk=; b=lK5TIAkMAjngL0PobJ33QYkUor3BuKiBVK2cKqe+/E+Fe6rEfqhfF9s3xpyyMrJwyj 5iG6cgac/HLei2QL2HCzClwjYJ1WchqF8gA+PsgV2rWcrb/akQDwwIm8iOoML9AvGwuD JnPU/gStFvZqQgRmS4GCkmU4BcqmgY66A/0R7IXWfno/vOXc1tdgTSZSIzA8OziLyOVu 4GqPDLZZAzvW8AHp5DMwV7xd0XuniFyG3Kr6n1SAE/7VeKeyCZgIuFz2Cv57C20tOxFG d4nZDlCR8f7ZtEBIfC36v+Gw/r9lQthge4/pR4lCCIU0saOknn4n0mPPTrIk6UfMmhBR MUwg== In-Reply-To: <20180119133510.GD6584-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: Andrey Ryabinin , Andrew Morton , Cgroups , LKML , Linux MM , Johannes Weiner , Vladimir Davydov On Fri, Jan 19, 2018 at 5:35 AM, Michal Hocko 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? > nack. If we ever see such a problem then reverting this patch should be > pretty straghtforward. > >> Signed-off-by: Andrey Ryabinin Reviewed-by: Shakeel Butt >> Cc: Shakeel Butt >> Cc: Michal Hocko >> Cc: Johannes Weiner >> Cc: Vladimir Davydov >> --- >> mm/memcontrol.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 9d987f3e79dc..09bac2df2f12 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2448,6 +2448,7 @@ static DEFINE_MUTEX(memcg_limit_mutex); >> static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> unsigned long limit, bool memsw) >> { >> + unsigned long nr_pages; >> bool enlarge = false; >> int ret; >> bool limits_invariant; >> @@ -2479,8 +2480,9 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> if (!ret) >> break; >> >> - if (!try_to_free_mem_cgroup_pages(memcg, 1, >> - GFP_KERNEL, !memsw)) { >> + nr_pages = max_t(long, 1, page_counter_read(counter) - limit); >> + if (!try_to_free_mem_cgroup_pages(memcg, nr_pages, >> + GFP_KERNEL, !memsw)) { >> ret = -EBUSY; >> break; >> } >> -- >> 2.13.6 >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo-Bw31MaZKKs0EbZ0PF+XxCw@public.gmane.org For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: email-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org > > -- > Michal Hocko > SUSE Labs