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 73DC4C433F5 for ; Mon, 18 Oct 2021 09:25:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0F8B060FC3 for ; Mon, 18 Oct 2021 09:25:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0F8B060FC3 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 A28D76B006C; Mon, 18 Oct 2021 05:25:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D8B1900002; Mon, 18 Oct 2021 05:25:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89FD76B0072; Mon, 18 Oct 2021 05:25:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) by kanga.kvack.org (Postfix) with ESMTP id 7AD2C6B006C for ; Mon, 18 Oct 2021 05:25:46 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2BFAD181CA35E for ; Mon, 18 Oct 2021 09:25:46 +0000 (UTC) X-FDA: 78709025892.40.2685D85 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf15.hostedemail.com (Postfix) with ESMTP id 45E29D000081 for ; Mon, 18 Oct 2021 09:25:43 +0000 (UTC) Received: by mail-qv1-f52.google.com with SMTP id v10so9857454qvb.10 for ; Mon, 18 Oct 2021 02:25:45 -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=c6G1gDX0KodcT+B+IPaHcSNxCrI3CJV8Wo022zcTGwY=; b=Ra8WWSozEac0AuCeiOFrRWfgnppu7WS7DGNDykXOGxBpKM1P9lpzj0zeBRV+r8AAXB VGFTxH9IKRhNmKZgsKGUGsI4txUCjgu86skcnWNDN64otXTKjqx4Ta1sQLN/1RkeCTzc Tppdw1eP+rBA3NZd+OXQvPCaij5XrGSslvH+uETiD3fOUgfVgaSuYFvs2Pi++HKuQW+q wKmrS0UQqrxBPXfs6z3YrRDkdwuSVYUDsvwMIO/lhJJpvU0/zng4eenKIGRd8gxd111B Wv1HcmygVlSROQEImkNou0WL06hWkltfwj7XsuvTIKxCI+Nk6APl0idJq/Dc2y/I5W9D YfYQ== 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=c6G1gDX0KodcT+B+IPaHcSNxCrI3CJV8Wo022zcTGwY=; b=jB+ipUCkckZhIvPNtriYc2IT7GD11Hrhrdw9aY+yB+Mh5Oc4XW6PuVcVSZIQKxa6jS Ffo8v7B+RhmvDaALiaohUHaHs21Xelp3xjR70d/IkXRXwrm02VWxXqL+UVLOkEP4UjlE FFZeLX0DC723Qs3A0aF7ATRc9krdVwyMo8EIk4jVilmol0Vy4OND8Gd8IiTamvAhCL3m s+4IH5DrFthSSUBu5KIoXepmF/69BnCMzzj0Ol8EUgaAZvRS5T3nFb9xl926/zRN/pj3 NGU8E4z4nJu7XYyQDAm1YU4NvPGKzQj83q01yk4IM/YUu5xr0tBWwg+eL+4928lEA2tp Gy3A== X-Gm-Message-State: AOAM533ibozsDGfOlLQcqIku/a20ty+I22CYZaGilkbl1ixH98t/gUbQ cLD6f2BYbex/pxsn4LLlFsWRMW7nD+NjshFvkv4= X-Google-Smtp-Source: ABdhPJxh7KWyCF/ta4V76CsvEyYDOdY1etMkJj+9Gv3xB9MkugEQQMgU5eo75x/AYAiXImlr0O7LXcyJi9mdnDKuOZU= X-Received: by 2002:ad4:5621:: with SMTP id cb1mr24448220qvb.6.1634549145111; Mon, 18 Oct 2021 02:25:45 -0700 (PDT) MIME-Version: 1.0 References: <1634278529-16983-1-git-send-email-huangzhaoyang@gmail.com> In-Reply-To: From: Zhaoyang Huang Date: Mon, 18 Oct 2021 17:25:23 +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: 45E29D000081 X-Stat-Signature: qp867tg64r8koho8mr65jpk5aftqo5ke Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ra8WWSoz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com X-HE-Tag: 1634549143-496149 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 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. > > Thanks! > > > memcg_memory_event(memcg, MEMCG_LOW); > > } > > > > -- > > 1.9.1 > > -- > Michal Hocko > SUSE Labs