From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED5E0C433F5 for ; Tue, 19 Oct 2021 07:11:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8CA4561390 for ; Tue, 19 Oct 2021 07:11:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8CA4561390 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 15DF66B006C; Tue, 19 Oct 2021 03:11:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 10D8B6B0071; Tue, 19 Oct 2021 03:11:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3ED8900002; Tue, 19 Oct 2021 03:11:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id E724A6B006C for ; Tue, 19 Oct 2021 03:11:53 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AAA523A2D7 for ; Tue, 19 Oct 2021 07:11:53 +0000 (UTC) X-FDA: 78712317306.20.DF9FC2C Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf09.hostedemail.com (Postfix) with ESMTP id B21993000100 for ; Tue, 19 Oct 2021 07:11:51 +0000 (UTC) Received: by mail-qt1-f169.google.com with SMTP id t16so17461391qto.5 for ; Tue, 19 Oct 2021 00:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P9RlSrpD0k5acoy5HGcKIkiOu7wRmSS2c551P7XRDbc=; b=kiZizcAMG4gRSTKk/t2DfuAaY6XX/nDU8h3k7j5TSPh9FPd477fMoX3jy2z1VslDkg ayOI4u+bmaMM6EVzGBB+d65nXJxQV9kKr60mxrM3NtaN48ZvmaesbLb2Vvd/L2ipjYHn MxIlCP+MkGKz5LMioLdnY1eFkNWH/VTTNV2kpVk0kkikh+b/31p+p2m5kiJtnOGkEZ1N GFhKPl0glKscAkB5cuTluG2xrlB4hY7HJC9RMI8oQ9Y0zde5PMYdRWwzBDP07ndHnh0x I2zbVj1x+cfI7ltC9obYgZVCx3C+2Wm8W9T532226u+ZP1uMddlwvvEbo+Bw9gzxNSa5 GlVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P9RlSrpD0k5acoy5HGcKIkiOu7wRmSS2c551P7XRDbc=; b=lgrx8dyKPMd80lGwOYhO8OTSdhVbt17UOdmQZzs+0lji7TvB7PP/uR7nQBGmkoTydu gPE6dtfgWn9pUc5uVOxZI+at+vPsRhiJMM1o1/L8oZZuvBcCugZwN4Sbw6mw/TYkKVhm B1LhfLOUizDhbzi88+Y9y72vo/Xn27O3A5C0s8MbUAxkgFzmWug98fFtQ1B0hr4fop82 8ztbVysTRRvqSwiCtm1do5tGETIipa48ViMGATCOOIIfQF3MgYoC/CfurQX5d/6FtRBW Ou956HOS0RxyE+y/45xLRkoAodrmQUkfQrISvOoKBCHYIefu+7h94y6pXH4pHJNqNG9f HglA== X-Gm-Message-State: AOAM530Ix87XgNFlSIB8gPN0D1Zv345ECwcrAnzMf3IDIR+iUTzEexLo 5g6O37DlNqpfOiZXNQUzvez9fbVNaECcHGzqgCA= X-Google-Smtp-Source: ABdhPJzvr8KVDzDd0NGKuLQYSEOd53sxI2EOeSHJ5WtYJ4i92PH5ks8i1sy4Po3lKr3pr+JiNd/Et8S9ZORAxrrZ3CY= X-Received: by 2002:ac8:580b:: with SMTP id g11mr34036446qtg.272.1634627512666; Tue, 19 Oct 2021 00:11:52 -0700 (PDT) MIME-Version: 1.0 References: <1634278529-16983-1-git-send-email-huangzhaoyang@gmail.com> In-Reply-To: From: Zhaoyang Huang Date: Tue, 19 Oct 2021 15:11:30 +0800 Message-ID: Subject: Re: [PATCH] mm: skip current when memcg reclaim To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Vladimir Davydov , Zhaoyang Huang , "open list:MEMORY MANAGEMENT" , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B21993000100 X-Stat-Signature: umf89s7ebkkbmaynmqt473q5rd3ohdi5 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kiZizcAM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-HE-Tag: 1634627511-582438 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 18, 2021 at 8:41 PM Michal Hocko wrote: > > On Mon 18-10-21 17:25:23, Zhaoyang Huang wrote: > > On Mon, Oct 18, 2021 at 4:23 PM Michal Hocko wrote: > > > > > > On Fri 15-10-21 14:15:29, Huangzhaoyang wrote: > > > > From: Zhaoyang Huang > > > > > > > > Sibling thread of the same process could refault the reclaimed pages > > > > in the same time, which would be typical in None global reclaim and > > > > introduce thrashing. > > > > > > It is hard to understand what kind of problem you see (ideally along > > > with some numbers) and how the proposed patch addresses that problem > > > > > > Also you are missing Signed-off-by tag (please have a look at > > > Documentation/process/submitting-patches.rst which is much more > > > comprehensive about the process). > > sorry for that, I will fix it. > > > > > > > --- > > > > mm/vmscan.c | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > > index 5199b96..ebbdc37 100644 > > > > --- a/mm/vmscan.c > > > > +++ b/mm/vmscan.c > > > > @@ -2841,6 +2841,11 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > > > > sc->memcg_low_skipped = 1; > > > > continue; > > > > } > > > > + /* > > > > + * Don't bother current when its memcg is below low > > > > + */ > > > > + if (get_mem_cgroup_from_mm(current->mm) == memcg) > > > > + continue; > > > > > > This code is executed when none of memcg in the reclaimed hierarchy > > > could be reclaimed. Low limit is then ignored and this change is > > > tweaking that behavior without any description of the effect. A very > > > vague note about trashing would indicate that you have something like > > > the following > > > > > > A (hiting hard limit) > > > / \ > > > B C > > > > > > Both B and C low limit protected and current task associated with B. As > > > none of the two could be reclaimed due to soft protection yuu prefer to > > > reclaim from C as you do not want to reclaim from the current process as > > > that could reclaim current's working set. Correct? > > > > > > I would be really curious about more specifics of the used hierarchy. > > What I am facing is a typical scenario on Android, that is a big > > memory consuming APP(camera etc) launched while background filled by > > other processes. The hierarchy is like what you describe above where B > > represents the APP and memory.low is set to help warm restart. Both of > > kswapd and direct reclaim work together to reclaim pages under this > > scenario, which can cause 20MB file page delete from LRU in several > > second. This change could help to have current process's page escape > > from being reclaimed and cause page thrashing. We observed the result > > via systrace which shows that the Uninterruptible sleep(block on page > > bit) and iowait get smaller than usual. > > I still have hard time to understand the exact setup and why the patch > helps you. If you want to protect B more than the low limit would allow > for by stealiong from C then the same thing can happen from anybody > reclaiming from C so in the end there is no protection. The same would > apply for any global direct memory reclaim done by a 3rd party. So I > suspect that your patch just happens to work by a luck. B and C compete fairly and superior than others. The idea based on assuming NOT all groups will trap into direct reclaim concurrently, so we want to have the groups steal pages from the processes under root(Non-memory sensitive) or other groups with lower thresholds(high memory tolerance) or the one totally sleeping(not busy for the time being, borrow some pages). > > Why both B and C have low limit setup and they both cannot be reclaimed? > Isn't that a weird setup where A hard limit is too close to sum of low > limits of B and C? > > In other words could you share a more detailed configuration you are > using and some more details why both B and C have been skipped during > the first pass of the reclaim? My practical scenario is that important processes(vip APP etc) are placed into protected memcg and keep other processes just under root. Current introduces direct reclaim because of alloc_pages(DMA_ALLOC etc), in which the number of allocation would be much larger than low but would NOT be charged to LRU. Whereas, current also wants to keep the pages(.so files to exec) on LRU. > > -- > Michal Hocko > SUSE Labs