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 68457C54FD0 for ; Tue, 21 Apr 2020 11:06:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3384B2075E for ; Tue, 21 Apr 2020 11:06:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3384B2075E 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 C95A48E0005; Tue, 21 Apr 2020 07:06:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C461A8E0003; Tue, 21 Apr 2020 07:06:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B352B8E0005; Tue, 21 Apr 2020 07:06:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 9D3D88E0003 for ; Tue, 21 Apr 2020 07:06:16 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5AC5A180AD82F for ; Tue, 21 Apr 2020 11:06:16 +0000 (UTC) X-FDA: 76731583152.01.pot99_199d7e89c6a5d X-HE-Tag: pot99_199d7e89c6a5d X-Filterd-Recvd-Size: 5698 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 11:06:15 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id f13so15953747wrm.13 for ; Tue, 21 Apr 2020 04:06:15 -0700 (PDT) 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=2nkEiPu8uzKgfWBfH+N6bOnXiYHqmdeCCwtF75WBrZI=; b=MYSJYuKuH3kl/PlP9wSlGeBsilNqWsTMeR0rCkvA8Scr8+efOc3758mjAPa07XoFyS AGf3rSKMPJDzEF56uqlR9mdz3hsKM/wK6wTP8dGD0F9NuyzE61bwOCSj8wJfbRjlp2K5 WWBNFtdznypqc3sTO68+K7aUobJpXrQQNxfgcqFHJKljnXxflH80l86OUeiEaSOXSCqP 49jkT6x7MfHGPu3Iqk1t4eWIccTcRw/HWfwIT3pr2kcvEWGHkBZZWobiM4GHRceOr28D C7u71H2Ms+59AznB9PBsUmlJPRFfpB1pOSYy6Kpu26dyYfVSat4Pwd9SHj18gDVlNwLA bAKg== X-Gm-Message-State: AGi0PuZUq1d99Yj6bonXUwO8Ht7gHMWOTeHdPTdtom5xB4xL9W2vMJyh E+bcAhio8iJ6hXf+Hzy0nGw= X-Google-Smtp-Source: APiQypI/MweFCuZznGg//eUIIqXcEw1/HuGfprCFuIVCQ6pCwNymcQ39WpMXnD/OF0nxFa5hDK+c8Q== X-Received: by 2002:a5d:4447:: with SMTP id x7mr23379143wrr.299.1587467174727; Tue, 21 Apr 2020 04:06:14 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id s11sm3251624wrw.71.2020.04.21.04.06.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2020 04:06:13 -0700 (PDT) Date: Tue, 21 Apr 2020 13:06:12 +0200 From: Michal Hocko To: Tejun Heo Cc: Shakeel Butt , Jakub Kicinski , Andrew Morton , Linux MM , Kernel Team , Johannes Weiner , Chris Down , Cgroups Subject: Re: [PATCH 0/3] memcg: Slow down swap allocation as the available space gets depleted Message-ID: <20200421110612.GD27314@dhcp22.suse.cz> References: <20200417173615.GB43469@mtj.thefacebook.com> <20200417193539.GC43469@mtj.thefacebook.com> <20200417225941.GE43469@mtj.thefacebook.com> <20200420164740.GF43469@mtj.thefacebook.com> <20200420170318.GV27314@dhcp22.suse.cz> <20200420170650.GA169746@mtj.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200420170650.GA169746@mtj.thefacebook.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: On Mon 20-04-20 13:06:50, Tejun Heo wrote: > Hello, > > On Mon, Apr 20, 2020 at 07:03:18PM +0200, Michal Hocko wrote: > > I have asked about the semantic of this know already and didn't really > > get any real answer. So how does swap.high fit into high limit semantic > > when it doesn't act as a limit. Considering that we cannot reclaim swap > > space I find this really hard to grasp. > > memory.high slow down is for the case when memory reclaim can't be depended > upon for throttling, right? This is the same. Swap can't be reclaimed so the > backpressure is applied by slowing down the source, the same way memory.high > does. Hmm, but the two differ quite considerably that we do not reclaim any swap which means that while no reclaimable memory at all is pretty much the corner case (essentially OOM) the no reclaimable swap is always in that state. So whenever you hit the high limit there is no other way then rely on userspace to unmap swap backed memory or increase the limit. Without that there is always throttling. The question also is what do you want to throttle in that case? Any swap backed allocation or swap based reclaim? The patch throttles any allocations unless I am misreading. This means that also any other !swap backed allocations get throttled as soon as the swap quota is reached. Is this really desirable behavior? I would find it quite surprising to say the least. I am also not sure about the isolation aspect. Because an external memory pressure might have pushed out memory to the swap and then the workload is throttled based on an external event. Compare that to the memory.high throttling which is not directly affected by the external pressure. There is also an aspect of non-determinism. There is no control over the file vs. swap backed reclaim decision for memcgs. That means that behavior is going to be very dependent on the internal implementation of the reclaim. More swapping is going to fill up swap quota quicker. > It fits together with memory.low in that it prevents runaway anon allocation > when swap can't be allocated anymore. It's addressing the same problem that > memory.high slowdown does. It's just a different vector. I suspect that the problem is more related to the swap being handled as a separate resource. And it is still not clear to me why it is easier for you to tune swap.high than memory.high. You have said that you do not want to set up memory.high because it is harder to tune but I do not see why swap is easier in this regards. Maybe it is just that the swap is almost never used so a bad estimate is much easier to tolerate and you really do care about runaways? -- Michal Hocko SUSE Labs