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 6D6D8C54FCB for ; Wed, 22 Apr 2020 18:49:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D14D2076E for ; Wed, 22 Apr 2020 18:49:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D14D2076E 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 665528E0006; Wed, 22 Apr 2020 14:49:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6155B8E0003; Wed, 22 Apr 2020 14:49:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52B488E0006; Wed, 22 Apr 2020 14:49:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id 384938E0003 for ; Wed, 22 Apr 2020 14:49:25 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E4ACA180AD81F for ; Wed, 22 Apr 2020 18:49:24 +0000 (UTC) X-FDA: 76736379048.19.point63_350b2a848a613 X-HE-Tag: point63_350b2a848a613 X-Filterd-Recvd-Size: 6110 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 18:49:24 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id f13so3710769wrm.13 for ; Wed, 22 Apr 2020 11:49:24 -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=FbPPWpYkZnIMG2RggwQqEZ2RVvkykjibS0WXqdLfUdQ=; b=N8Y6Y+rkq9M/yVNCcB09ViGvK7PaR/k61STUow9gnLcJn/+BTf6dyKJ7w87Dpk/MoJ VwesvSqMr2eS2/eQRM8N1g11V2mXDJfp2F2St7Bo7HU7e6L27zenx1PGC+BtzvM8O0Ax 13lKpqkFFIL4bcq4wnS3YFkiVD2uwPj/INnctfGqscSXN5MGqmI0RRWgWJQkSO11N6xq NdS9XhsdE4cvtQfuFlfmAu/nRnTS9BXTbnIQtjMYjGYMKqC6m6U2JuJxtO/yojrrCme/ Gptkz4/97eSkxCVHcwWEfDL5Wght5lDQWB0uM6SPUxxdyIdfx7M715BZ45MLUQJWqU+a 0EHg== X-Gm-Message-State: AGi0Pua9pJPu5UE2dLQTKxfyywWAg+1fweT5elM8aOL+7Nh1fkSRMiDl J0YCtXUoY3/dMpHJrp3Vs0I= X-Google-Smtp-Source: APiQypL8dFHQu9vVFnP6IiwOlw0Ztqt4pCV4ecVJhEgtDndI2BkMJQtw83n0sbXbQJI2YI9mPHyWoQ== X-Received: by 2002:a5d:6302:: with SMTP id i2mr519579wru.80.1587581363265; Wed, 22 Apr 2020 11:49:23 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id x132sm201271wmg.33.2020.04.22.11.49.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2020 11:49:22 -0700 (PDT) Date: Wed, 22 Apr 2020 20:49:21 +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: <20200422184921.GB4206@dhcp22.suse.cz> References: <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> <20200422154318.GK30312@dhcp22.suse.cz> <20200422171328.GC362484@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200422171328.GC362484@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 13:13:28, Johannes Weiner wrote: > On Wed, Apr 22, 2020 at 05:43:18PM +0200, Michal Hocko wrote: > > On Wed 22-04-20 10:15:14, Johannes Weiner wrote: [...] > > > + 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 honestly don't really follow you here. Why is it not helpful to say > all allocations will slow down when condition X is met? This might be just me and I definitely do not want to pick on words here but your wording was not specific on which allocations. You can very well interpret that as really all allocations but I wouldn't be surprised if some would interpret it in a way that the kernel doesn't throttle unnecessarily and if allocations cannot really contribute to more swap then why should they be throttled. > We do the same for memory.high. > > > 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 > > I think we may be talking past each other. The user can do the same > thing as in any OOM situation: wait for the kill. That assumes that reaching swap.high is going to converge to the OOM eventually. And that is far from the general case. There might be a lot of other reclaimable memory to reclaim and stay in the current state. [...] > > 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. > > " > > I mean, in rare cases, maybe userspace can do some loadshedding and be > smart about it. But we certainly don't expect it to. I really didn't mean to suggest any clever swap management. All I wanted so say and have documented is that users of swap.high should be aware of the fact that kernel is not able to do much to reduce the throttling. This is really different from memory.high where the kernel pro-actively tries to keep the memory usage below the watermark. So a certain level of userspace cooperation is really needed unless you can tolerate a workload to be throttled to the end of times. So let me be clear here. This is a very tricky interface to use and the more verbose we can be the better. -- Michal Hocko SUSE Labs