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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDE48C43603 for ; Wed, 18 Dec 2019 14:09:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AE4C52176D for ; Wed, 18 Dec 2019 14:09:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="PNyhx+AO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE4C52176D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 490B98E0111; Wed, 18 Dec 2019 09:09:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4409E8E00F5; Wed, 18 Dec 2019 09:09:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 355E58E0111; Wed, 18 Dec 2019 09:09:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 1D4408E00F5 for ; Wed, 18 Dec 2019 09:09:56 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id C8A872476 for ; Wed, 18 Dec 2019 14:09:55 +0000 (UTC) X-FDA: 76278445950.22.milk39_1c66e91070518 X-HE-Tag: milk39_1c66e91070518 X-Filterd-Recvd-Size: 4588 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Dec 2019 14:09:55 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id d16so2428189wre.10 for ; Wed, 18 Dec 2019 06:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dxjsGjatY6ZbcTCcZP76IfB6Z3ogOgfOc4zopQ9KHZw=; b=PNyhx+AOrNKPg3eDV8ybExNCbharLbfTnb/QPJsivs4Drc+dFrkWLrZiSpJzm/dOol 5cwzbkNc0l3rz6AIjkIRe7L/lvDQUdnn4yZCYUv6VZJkKbn7U9Nyh7g83AWJylEcGA3W d4ZLDHApZ7hFNqnvcOOIs2oZSjbuNQKWIlnAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dxjsGjatY6ZbcTCcZP76IfB6Z3ogOgfOc4zopQ9KHZw=; b=arH7Xkj2uQWf1tvOPggqm8cx0v+zUfSF0Vk47KO5MNOOdREh4qEqr8K9PL8oRsre3B l1Gg025dn5sN98/cONZ8oJEb0oX15hWNilCuGT5bqCbECD2nHKXNoXpyCGqO4IJExBVZ /EchD9STqe0/mbNrg47Y5RY+oTJL5ShJwbdfeMAcN9lf/WFfZ8Pj8k5RFuGI4JhmwHrZ ITm10Cu7MPKpWoPeqVE/UvgMMr3rFTseBLR6DkSHalhhoOkYEAC6EOv4aAzWxyELsMn3 rd2v3prfn1f+8hpJDB3N/Ttp+lYZYCxCZPL4C09rKmbEJVKHwkFE7O0u4iZOcxTFYFep HbLA== X-Gm-Message-State: APjAAAXfZKEYpQK3utYWc3ViofxNN57JFL39tOZkSU02khE/m0CaaGl6 rKaVeif4zbm2oGxTlrcO4l+XJQ== X-Google-Smtp-Source: APXvYqxbgaqnKp6+tHcSJR0Hg+KDMISaNFHSKVH0qfn81gYVnqcpO9RInQXrM6+/f4otf0uySVZMdA== X-Received: by 2002:adf:b591:: with SMTP id c17mr3068382wre.108.1576678193639; Wed, 18 Dec 2019 06:09:53 -0800 (PST) Received: from localhost ([2a01:4b00:8432:8a00:63de:dd93:20be:f460]) by smtp.gmail.com with ESMTPSA id o194sm2641065wme.45.2019.12.18.06.09.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Dec 2019 06:09:53 -0800 (PST) Date: Wed, 18 Dec 2019 14:09:52 +0000 From: Chris Down To: Hui Zhu Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, guro@fb.com, shakeelb@google.com, yang.shi@linux.alibaba.com, tj@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: vmscan: memcg: Add global shrink priority Message-ID: <20191218140952.GA255739@chrisdown.name> References: <1576662179-16861-1-git-send-email-teawaterz@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1576662179-16861-1-git-send-email-teawaterz@linux.alibaba.com> 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: Hi Hui, In general cgroup v1 is in maintenance mode -- that is, excepting specific bugfixes, we don't plan to add new features. Hui Zhu writes: >Currently, memcg has some config to limit memory usage and config >the shrink behavior. >In the memory-constrained environment, put different priority tasks >into different cgroups with different memory limits to protect the >performance of the high priority tasks. Because the global memory >shrink will affect the performance of all tasks. The memory limit >cgroup can make shrink happen inside the cgroup. Then it can decrease >the memory shrink of the high priority task to protect its performance. > >But the memory footprint of the task is not static. It will change as >the working pressure changes. And the version changes will affect it too. >Then set the appropriate memory limit to decrease the global memory shrink >is a difficult job and lead to wasted memory or performance loss sometimes. > >This commit adds global shrink priority to memcg to try to handle this >problem. I have significant concerns with exposing scan priority to userspace. This is an incredibly difficult metric for users to reason about since it's a reclaim implementation feature and would add to an already confusing and fragmented API in v1. Have you considered using memory protection (memory.low, memory.min) for this instead? It sounds like it can achieve the results you want, in that it allows you to direct and prioritise reclaim in a way that allows for ballparking (ie. it is compatible with applications with variable memory footprints). Thanks, Chris