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=-1.0 required=3.0 tests=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 83B84C11D05 for ; Thu, 20 Feb 2020 16:19:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5009420659 for ; Thu, 20 Feb 2020 16:19:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5009420659 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 D46306B000A; Thu, 20 Feb 2020 11:19:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF6BC6B000C; Thu, 20 Feb 2020 11:19:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE4A46B000D; Thu, 20 Feb 2020 11:19:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id A5C896B000A for ; Thu, 20 Feb 2020 11:19:19 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5B37618036D67 for ; Thu, 20 Feb 2020 16:19:19 +0000 (UTC) X-FDA: 76511015238.22.berry90_5151242a77a4f X-HE-Tag: berry90_5151242a77a4f X-Filterd-Recvd-Size: 3506 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Feb 2020 16:19:18 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id a9so2707083wmj.3 for ; Thu, 20 Feb 2020 08:19:18 -0800 (PST) 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=sF/QS2W9VL9GASwwaF/6cokRPHYZNgTr5BkwNXpLMzM=; b=OdI6j0WeifoXNFjtwcJVLq69Kk+3o8pAazTB12FoO2jXltE90/Y9lP+deKtN3gYs5w Zm9W8Rtr2s9dHQ8rCk1+jieGvy4UY7pnw9pTiLo9FimIQfQOE+FEiAw1VGm/Hz5mPCtc 4OjYOSlInYL6g9LRWCCoMLU7GV6ppfq0kZmeZ1GKmNeNkiT9SCs/neleVNLiuBPcZyAr 2/1jxenKi8l9okIY0JJPeJ7hM1KfgnjDihEh3abvjh6AmkSnx9nnF5gBQrBuevVQ1doj HQvYK0lEA87KHsWY8BdOUBFG7d2+BFwvV8k8VTwtff9k4LXpGV+Ua3iODxlPh7XhFXop 9AeA== X-Gm-Message-State: APjAAAXB5ib8VGEnCI7mio0KW80Zccfhckmzx2OvYun942tw+JyNLxOM 3767nG4XsFwx4hIWrWd6tUc= X-Google-Smtp-Source: APXvYqwheNbif3Gz60xPhk+whepcAvzF5huQ4t6NSDuQfW8P2UBW+3eRjqw6AGcq7oy7fWfxtWcq0Q== X-Received: by 2002:a1c:bdc6:: with SMTP id n189mr5488376wmf.102.1582215557559; Thu, 20 Feb 2020 08:19:17 -0800 (PST) Received: from localhost (ip-37-188-133-21.eurotel.cz. [37.188.133.21]) by smtp.gmail.com with ESMTPSA id y6sm56237wrl.17.2020.02.20.08.19.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 08:19:16 -0800 (PST) Date: Thu, 20 Feb 2020 17:19:15 +0100 From: Michal Hocko To: "Kirill A. Shutemov" Cc: Tim Chen , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Dave Hansen , Dan Williams , Huang Ying Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Memory cgroups, whether you like it or not Message-ID: <20200220161915.GI20509@dhcp22.suse.cz> References: <20200214104541.GT31689@dhcp22.suse.cz> <20200220160604.ak33n3hrqouyiuyv@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200220160604.ak33n3hrqouyiuyv@box> 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 20-02-20 19:06:04, Kirill A. Shutemov wrote: > On Fri, Feb 14, 2020 at 11:45:41AM +0100, Michal Hocko wrote: > > On Wed 05-02-20 10:34:57, Tim Chen wrote: > > > There is existing infrastructure for memory soft limit per cgroup we > > > can leverage to implement such a scheme. We'll like to find out if this > > > approach makes sense for people working on systems with multiple memory tiers. > > > > Soft limit is dead. > > Michal, could you remind what the deal with soft limit? Why is it dead? because of the very disruptive semantic. Essentially the way how it was grafted into the normal reclaim. It is essentially a priority 0 reclaim round to shrink a hierarchy which is the most in excess before we do a normal reclaim. This can lead to an over reclaim, long stalls etc. There were a lot of discussions on that matter on the mailing list few years back. We have tried to make the semantic more reasonable but failed on that and the result is a new cgroup v2 interface essentially. -- Michal Hocko SUSE Labs