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.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 90240C54FC9 for ; Tue, 21 Apr 2020 15:21:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 47DBF2068F for ; Tue, 21 Apr 2020 15:21:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FXrADtfB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47DBF2068F 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 E453F8E0005; Tue, 21 Apr 2020 11:21:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF8118E0003; Tue, 21 Apr 2020 11:21:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBDBD8E0005; Tue, 21 Apr 2020 11:21:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id B1EC68E0003 for ; Tue, 21 Apr 2020 11:21:22 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6F7BE82499B9 for ; Tue, 21 Apr 2020 15:21:22 +0000 (UTC) X-FDA: 76732226004.03.war00_419bef6a9ae09 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 5E6A628A4EB for ; Tue, 21 Apr 2020 15:20:53 +0000 (UTC) X-HE-Tag: war00_419bef6a9ae09 X-Filterd-Recvd-Size: 5795 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 15:20:50 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id i68so6134297qtb.5 for ; Tue, 21 Apr 2020 08:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jwGeQzDdrOzdJlAD0ghWVZoxVjm5XtEA2WK3XkkvxyQ=; b=FXrADtfByQlNUBEu1vViyehbFKOhBU4dp73jUXSMQGEAoigcpdrozcO5N83yOhXOq7 +ukk+fWtA9qV3xkAfsTaSRJ9oHuy247FfqCAQoc9ctvnDd5qagUr9M9GMJRKjbEypcuE y7tMsSMoVKMH0y8GXyRFyqKVVXLlvT5p+2bN225RNns1qJ4BaWr90ubNBeg0E8aZa1cP vdmlxNuhT6GxrpDAx8ygVkMC6JUmhFQjeD0e6jYj7GGdQZEIQFikaRxvASiVC9jWHSst KWoB96kLu/3CiDEYFNffV1ofM8GWKhn4Z7D8wyf0iLMsCXR5Np1H2q+J9zCgeSt2ZI82 H3Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=jwGeQzDdrOzdJlAD0ghWVZoxVjm5XtEA2WK3XkkvxyQ=; b=C5We+iWMZLOWrlGYF4YWzzkOWjFdUAG0w4vGntQyvVIngF1iiXAbJhgYMA6TKfvynt Aag3tGOqdSSzQOhDlNuQ629JkuS96VJmXq3JFnmQ8TnUUQUB93cL9kUxEB0X6aM2IvD+ fl//gscg06GH1GC49Jj3sw2AiNOaudKrQSYYfOIefhXFH3euIsNTXg+bv1KAmAOiqCpK UuwoXFoEwj+gh2AI6ySYNGVG0gzj8JO3Lum5NxITsx5yQ57QZef4nRHHrhGREvIY36bS Yc1cbzrtUaIQjRfbwIB/xt3Wx1KP9s6wR9yu189RT9s25FDqKM0J+MBpfmNOWAXkHuv6 Psew== X-Gm-Message-State: AGi0PuY51BOD4xoC4jCX8n2S2kMvunQLZ2WHPUCNFCF86vby9hLUSmGN pTz8bXV7aPSmCUpBLyN0MAI= X-Google-Smtp-Source: APiQypKA30+eSP0g8fNHbH1LI6/q74o+Jz6pppFA2VazsE3KBb6jIhN1/k/smTSq+IrQK+28Z0LPyA== X-Received: by 2002:ac8:38eb:: with SMTP id g40mr21980140qtc.386.1587482449928; Tue, 21 Apr 2020 08:20:49 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:6b75]) by smtp.gmail.com with ESMTPSA id p2sm1941810qkm.65.2020.04.21.08.20.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2020 08:20:49 -0700 (PDT) Date: Tue, 21 Apr 2020 11:20:47 -0400 From: Tejun Heo To: Michal Hocko 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: <20200421152047.GA5462@mtj.thefacebook.com> 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> <20200421110612.GD27314@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421110612.GD27314@dhcp22.suse.cz> 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: Hello, On Tue, Apr 21, 2020 at 01:06:12PM +0200, Michal Hocko wrote: > 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? Johannes responded a lot better. I'm just gonna add a bit here. Swap is intertwined with memory but is a very different resource from memory. You can't seriously equate primary and secondary storages. We never want to underutilize memory but we never want to completely fill up secondary storage. They're exactly the opposite in that sense. It's not that protection schemes can't apply to swap but that such level of dynamic control isn't required because simple upper limit is useful and easy enough. Another backing point I want to raise is that the abrupt transition which happens on swap depletion is a real problem that userspace has been trying to work around. memory.low based protection and oomd is an obvious example but not the only one. earlyoom[1] is an independent project which predates all these things and kills when swap runs low to protect the system from going down the gutter. In this respect, both oomd and earlyoom basically do the same thing but they're racing against the kernel filling up the space. Once the swap space is gone, the programs themselves might not be able to make reasonable forward progress. The only measure they can currently employ is polling more frequently and killing ealier so that swap space never actually runs out, but it's a silly and losing game as the underyling device gets faster and faster. Note that at least fedora is considering including either earlyoom or oomd by default. The problem addressed by swap.high is real and immediate. Thanks. -- tejun [1] https://github.com/rfjakob/earlyoom