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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 29450C33C8C for ; Mon, 6 Jan 2020 13:10:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C25C32071A for ; Mon, 6 Jan 2020 13:10:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C25C32071A 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 2B6D18E0005; Mon, 6 Jan 2020 08:10:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 267BD8E0001; Mon, 6 Jan 2020 08:10:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17E398E0005; Mon, 6 Jan 2020 08:10:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id F1C308E0001 for ; Mon, 6 Jan 2020 08:10:23 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 9688E181AC9CC for ; Mon, 6 Jan 2020 13:10:23 +0000 (UTC) X-FDA: 76347243126.08.push11_207cad6a17915 X-HE-Tag: push11_207cad6a17915 X-Filterd-Recvd-Size: 4017 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Jan 2020 13:10:23 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id 20so15163369wmj.4 for ; Mon, 06 Jan 2020 05:10:23 -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:user-agent; bh=Vu9QJE4YseoFoORr+glUnjER2lum2n5Fmao9NtM3PIE=; b=a8vEZ+xj03zHNlFMM6FoOyTH/hVnuHQ/E4p9FU11UU618m1w9fJwAycBnCuq+eDwBM sHHmElNmyalR+mBFJJdBJU4hXVZnPFjQ9EPWhvHzmA4nONDBgJA4T0pAZQIJgrI09gPh f77kRqW3aCkkSm1Id8sd4TY3IeLTqhiTB1/VJdFEqQmksS606va42YEngDybQPpWTfcE rU0sQFqTXMetr8BZ6vHAlBQPrx3W56f0iwyPe7ybC9wFNT2hW+jFoKTvc0vowbmSXYSR E1T1X+1BJn/L+mvkKvEw7QmphMmCt0/iaA9I8jm7ZLdGlpCRa3WpJSabNT1ESCpvECma G3Zw== X-Gm-Message-State: APjAAAWnPzAZKcF6inDDa6AWQ+B6xC8zspnRf/r93C6B0SODlo3VLukg 4UZLKv+k2sFiV30+YQd6mXg= X-Google-Smtp-Source: APXvYqy98p6Gbv57CrgSCBw3//qlqbjd/XfXAeKhQJgUAMjp7jA95LuY+c3vWDw4ljcd4TFaL06olQ== X-Received: by 2002:a1c:4d03:: with SMTP id o3mr34937526wmh.164.1578316222081; Mon, 06 Jan 2020 05:10:22 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id b137sm23650193wme.26.2020.01.06.05.10.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2020 05:10:21 -0800 (PST) Date: Mon, 6 Jan 2020 14:10:20 +0100 From: Michal Hocko To: Chris Down Cc: Hui Zhu , hannes@cmpxchg.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Hui Zhu Subject: Re: [RFC] memcg: Add swappiness to cgroup2 Message-ID: <20200106131020.GC9198@dhcp22.suse.cz> References: <1577252208-32419-1-git-send-email-teawater@gmail.com> <20191225140546.GA311630@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191225140546.GA311630@chrisdown.name> User-Agent: Mutt/1.12.2 (2019-09-21) 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 25-12-19 14:05:46, Chris Down wrote: > Hi Hui, > > Hui Zhu writes: > > Even if cgroup2 has swap.max, swappiness is still a very useful config. > > This commit add swappiness to cgroup2. > > When submitting patches like this, it's important to explain *why* you want > it and what evidence there is. For example, how should one use this to > compose a reasonable system? Why aren't existing protection controls > sufficient for your use case? Where's the data? Agreed! > Also, why would swappiness be something cgroup-specific instead of > hardware-specific, when desired swappiness is really largely about the > hardware you have in your system? I am not really sure I agree here though. Swappiness has been traditionally more about workload because it has been believed that it is a preference of the workload whether the anonymous or disk based memory is more important. Whether this is a good interface is debatable of course but time has shown that it is extremely hard to tune. Not to mention that swappiness has been ignored for years for vast majority workloads because of the highly biased file LRU reclaim. At the time when cgroup v2 was introduced it'd been claimed that we do not want to copy the v1 swappiness logic because of the semantic shortcomings and that a better tuning should developed in future replacing even the global knob. AFAIR Johannes wanted to have a refault vs. cost based file/anon balancing. The lack of a sensible hierarchical behavior has been even a stronger argument. -- Michal Hocko SUSE Labs