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=-5.5 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 2ED56C49ED7 for ; Thu, 19 Sep 2019 13:32:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F1CFB218AF for ; Thu, 19 Sep 2019 13:32:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1CFB218AF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7EE5C6B0359; Thu, 19 Sep 2019 09:32:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79ED36B035B; Thu, 19 Sep 2019 09:32:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68D476B035C; Thu, 19 Sep 2019 09:32:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0079.hostedemail.com [216.40.44.79]) by kanga.kvack.org (Postfix) with ESMTP id 42B456B0359 for ; Thu, 19 Sep 2019 09:32:27 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 97412824CA22 for ; Thu, 19 Sep 2019 13:32:26 +0000 (UTC) X-FDA: 75951759492.07.spot66_89b0dd02a3801 X-HE-Tag: spot66_89b0dd02a3801 X-Filterd-Recvd-Size: 3055 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Sep 2019 13:32:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5D6C1AFC4; Thu, 19 Sep 2019 13:32:24 +0000 (UTC) Date: Thu, 19 Sep 2019 15:32:22 +0200 From: Michal Hocko To: Hillf Danton Cc: Johannes Weiner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Roman Gushchin , Matthew Wilcox Subject: Re: [RFC] mm: memcg: add priority for soft limit reclaiming Message-ID: <20190919133222.GD15782@dhcp22.suse.cz> References: <20190919131332.4180-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190919131332.4180-1-hdanton@sina.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Thu 19-09-19 21:13:32, Hillf Danton wrote: > > Currently memory controler is playing increasingly important role in > how memory is used and how pages are reclaimed on memory pressure. > > In daily works memcg is often created for critical tasks and their pre > configured memory usage is supposed to be met even on memory pressure. > Administrator wants to make it configurable that the pages consumed by > memcg-B can be reclaimed by page allocations invoked not by memcg-A but > by memcg-C. I am not really sure I understand the usecase well but this sounds like what memory reclaim protection in v2 is aiming at. > That configurability is addressed by adding priority for soft limit > reclaiming to make sure that no pages will be reclaimed from memcg of > higer priortiy in favor of memcg of lower priority. cgroup v1 interfaces are generally frozen and mostly aimed at backward compatibility. I am especially concerned about adding a new way to control soft limit which is known to be misdesigned and unfixable to behave reasonably. > Pages are reclaimed with no priority being taken into account by default > unless user turns it on, and then they are responsible for their smart > activities almost the same way as they play realtime FIFO/RR games. > > Priority is available only in the direct reclaiming context in order to > advoid churning in the complex kswapd behavior. > > Cc: Shakeel Butt > Cc: Roman Gushchin > Cc: Matthew Wilcox > Cc: Johannes Weiner > Cc: Michal Hocko > Signed-off-by: Hillf Danton That being said, you should describe the usecase and explain why v2 interface is not providing what you need. We might think about where to go from there but extending the soft limit reclaim is almost certainly not the right way to go. -- Michal Hocko SUSE Labs