From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by kanga.kvack.org (Postfix) with ESMTP id 9006F6B0038 for ; Mon, 20 Mar 2017 04:18:58 -0400 (EDT) Received: by mail-lf0-f72.google.com with SMTP id v2so68753498lfi.2 for ; Mon, 20 Mar 2017 01:18:58 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com. [2a00:1450:4010:c07::232]) by mx.google.com with ESMTPS id n6si3987853lje.92.2017.03.20.01.18.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 01:18:56 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id j90so52211483lfk.2 for ; Mon, 20 Mar 2017 01:18:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170317231636.142311-1-timmurray@google.com> References: <20170317231636.142311-1-timmurray@google.com> From: Kyungmin Park Date: Mon, 20 Mar 2017 17:18:55 +0900 Message-ID: Subject: Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Tim Murray Cc: Johannes Weiner , Michal Hocko , Vladimir Davydov , Linux Kernel Mailing List , cgroups@vger.kernel.org, linux-mm , surenb@google.com, totte@google.com, Android Kernel Team , Kyungmin Park On Sat, Mar 18, 2017 at 8:16 AM, Tim Murray wrote: > Hi all, > > I've been working to improve Android's memory management and drop lowmemo= rykiller from the kernel, and I'd like to get some feedback on a small patc= h with a lot of side effects. > > Currently, when an Android device is under memory pressure, one of three = things will happen from kswapd: > > 1. Compress an anonymous page to ZRAM. > 2. Evict a file page. > 3. Kill a process via lowmemorykiller. > > The first two are cheap and per-page, the third is relatively cheap in th= e short term, frees many pages, and may cause power and performance penalti= es later on when the process has to be started again. For lots of reasons, = I'd like a better balance between reclamation and killing on Android. > > One of the nice things about Android from an optimization POV is that the= execution model is more constrained than a generic Linux machine. There ar= e only a limited number of processes that need to execute quickly for the d= evice to appear to have good performance, and a userspace daemon (called Ac= tivityManagerService) knows exactly what those processes are at any given t= ime. We've made use of that in the past via cpusets and schedtune to limit = the CPU resources available to background processes, and I think we can app= ly the same concept to memory. > > This patch adds a new tunable to mem cgroups, memory.priority. A mem cgro= up with a non-zero priority will not be eligible for scanning until the sca= n_control's priority is greater than zero. Once the mem cgroup is eligible = for scanning, the priority acts as a bias to reduce the number of pages tha= t should be scanned. Here's old discussion to support app-per-memcg reclaim "[PATCH] memcg: Add force_reclaim to reclaim tasks' memory in memcg." http://www.spinics.net/lists/cgroups/msg07874.html unlike existing interface, it can reclaim the memory while process is still in memcg. In our case, it's used for reclaim and swap out pages for that app. Thank you, Kyungmin Park > > We've seen cases on Android where the global LRU isn't sufficient. For ex= ample, notifications in Android are rendered as part of a separate process = that runs infrequently. However, when a notification appears and the user s= lides down the notification tray, we'll often see dropped frames due to pag= e faults if there has been severe memory pressure. There are similar issues= with other persistent processes. > > The goal on an Android device is to aggressively evict from very low-prio= rity background tasks that are likely to be killed anyway, since this will = reduce the likelihood of lowmemorykiller running in the first place. It wil= l still evict some from foreground and persistent processes, but it should = help ensure that background processes are effectively reduced to the size o= f their heaps before evicting from more critical tasks. This should mean fe= wer background processes end up killed, which should improve performance an= d power on Android across the board (since it costs significantly less to p= age things back in than to replay the entirety of application startup). > > The follow-on that I'm also experimenting with is how to improve vmpressu= re such that userspace can have some idea when low-priority memory cgroups = are about as small as they can get. The correct time for Android to kill a = background process under memory pressure is when there is evidence that a p= rocess has to be killed in order to alleviate memory pressure. If the devic= e is below the low memory watermark and we know that there's probably no wa= y to reclaim any more from background processes, then a userspace daemon sh= ould kill one or more background processes to fix that. Per-cgroup priority= could be the first step toward that information. > > I've tested a version of this patch on a Pixel running 3.18 along with an= overhauled version of lmkd (the Android userspace lowmemorykiller daemon),= and it does seem to work fine. I've ported it forward but have not yet rig= orously tested it at TOT, since I don't have an Android test setup running = TOT. While I'm getting my tests ported over, I would like some feedback on = adding another tunable as well as what the tunable's interface should be--I= really don't like the 0-10 priority scheme I have in the patch but I don't= have a better idea. > > Thanks, > Tim > > Tim Murray (1): > mm, memcg: add prioritized reclaim > > include/linux/memcontrol.h | 20 +++++++++++++++++++- > mm/memcontrol.c | 33 +++++++++++++++++++++++++++++++++ > mm/vmscan.c | 3 ++- > 3 files changed, 54 insertions(+), 2 deletions(-) > > -- > 2.12.0.367.g23dc2f6d3c-goog > > -- > 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 -- 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