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=-4.0 required=3.0 tests=INCLUDES_PATCH, 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 05DFBC55185 for ; Wed, 22 Apr 2020 15:43:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C3DD32076E for ; Wed, 22 Apr 2020 15:43:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C3DD32076E 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 717EF8E000C; Wed, 22 Apr 2020 11:43:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A2078E0003; Wed, 22 Apr 2020 11:43:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5698E8E000C; Wed, 22 Apr 2020 11:43:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0234.hostedemail.com [216.40.44.234]) by kanga.kvack.org (Postfix) with ESMTP id 3A6C28E0003 for ; Wed, 22 Apr 2020 11:43:22 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E47893CE9 for ; Wed, 22 Apr 2020 15:43:21 +0000 (UTC) X-FDA: 76735910202.08.nut14_1d563a3a60911 X-HE-Tag: nut14_1d563a3a60911 X-Filterd-Recvd-Size: 5450 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 15:43:21 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id g12so2941714wmh.3 for ; Wed, 22 Apr 2020 08:43:21 -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=1oRxBMnlbBMPhg1L3MrHQ8H+9dmimSCtvmaiZgbijlY=; b=VziFZWB/aDP++NJnrdAtqhLCQzJo5tdpXd8m6FWltAUnguneIqHT9BIsUumxgU8dll W6hzTALUE1dEmPga8g6o4ixMICZAn/kc7cRM0yW6iAEuLGS4vS+ID5aZVxLg9uKWY+NG dtSFgFTRBUxWzBU6F284LmVcchWwSKk3MKOjpSdhMXnrOS5cIjhrZ4jnM3UVPoNpc6RA 97aC2PxedNnDPKPZLUQW5mvhU8zkekPYA/icYBlL6DIde9AOCxNKX+ccVBE+x8ewUgH+ dqIMknorkrbpjkNAaLFjz+PsZx4gD24xtfdnMHtGsSViS+tEhoiSHuGACEz8pNuwsDqM jGag== X-Gm-Message-State: AGi0Pubv0dN3mrbACTOGwxi44voDhoitNLXCFTgkzrbXyoCV6heASf+k 8qS1cSzhcXrd2/SrYI5qG8A= X-Google-Smtp-Source: APiQypLD5BLDakIwmSbPvkTKgrzmnmj6tvj/nRSOQHRq7MmLkYK7jQGjhOv9Lrx0tPKRsL9l1Kbq/g== X-Received: by 2002:a1c:c30a:: with SMTP id t10mr10589958wmf.80.1587570200281; Wed, 22 Apr 2020 08:43:20 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id s18sm9424846wra.94.2020.04.22.08.43.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2020 08:43:19 -0700 (PDT) Date: Wed, 22 Apr 2020 17:43:18 +0200 From: Michal Hocko To: Johannes Weiner Cc: Tejun Heo , Shakeel Butt , Jakub Kicinski , Andrew Morton , Linux MM , Kernel Team , Chris Down , Cgroups Subject: Re: [PATCH 0/3] memcg: Slow down swap allocation as the available space gets depleted Message-ID: <20200422154318.GK30312@dhcp22.suse.cz> References: <20200420164740.GF43469@mtj.thefacebook.com> <20200420170318.GV27314@dhcp22.suse.cz> <20200420170650.GA169746@mtj.thefacebook.com> <20200421110612.GD27314@dhcp22.suse.cz> <20200421142746.GA341682@cmpxchg.org> <20200421161138.GL27314@dhcp22.suse.cz> <20200421165601.GA345998@cmpxchg.org> <20200422132632.GG30312@dhcp22.suse.cz> <20200422141514.GA362484@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200422141514.GA362484@cmpxchg.org> 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 Wed 22-04-20 10:15:14, Johannes Weiner wrote: > On Wed, Apr 22, 2020 at 03:26:32PM +0200, Michal Hocko wrote: > > That being said I believe our discussion is missing an important part. > > There is no description of the swap.high semantic. What can user expect > > when using it? > > Good point, we should include that in cgroup-v2.rst. How about this? > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > index bcc80269bb6a..49e8733a9d8a 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -1370,6 +1370,17 @@ PAGE_SIZE multiple when read back. > The total amount of swap currently being used by the cgroup > and its descendants. > > + memory.swap.high > + A read-write single value file which exists on non-root > + cgroups. The default is "max". > + > + Swap usage throttle limit. If a cgroup's swap usage exceeds > + this limit, allocations inside the cgroup will be throttled. Hm, so this doesn't talk about which allocatios are affected. This is good for potential future changes but I am not sure this is useful to make any educated guess about the actual effects. One could expect that only those allocations which could contribute to future memory.swap usage. I fully realize that we do not want to be very specific but we want to provide something useful I believe. I am sorry but I do not have a good suggestion on how to make this better. Mostly because I still struggle on how this should behave to be sane. I am also missing some information about what the user can actually do about this situation and call out explicitly that the throttling is not going away until the swap usage is shrunk and the kernel is not capable of doing that on its own without a help from the userspace. This is really different from memory.high which has means to deal with the excess and shrink it down in most cases. The following would clarify it for me "Once the limit is exceeded it is expected that the userspace is going to act and either free up the swapped out space or tune the limit based on needs. The kernel itself is not able to do that on its own. " > + > + This slows down expansion of the group's memory footprint as > + it runs out of assigned swap space. Compare to memory.swap.max, > + which stops swapping abruptly and can provoke kernel OOM kills. > + > memory.swap.max > A read-write single value file which exists on non-root > cgroups. The default is "max". -- Michal Hocko SUSE Labs