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=-13.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 5B5A9C433E0 for ; Wed, 6 Jan 2021 16:42:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 10F982311E for ; Wed, 6 Jan 2021 16:42:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10F982311E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2F9CC6B02A0; Wed, 6 Jan 2021 11:42:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D03A6B02A2; Wed, 6 Jan 2021 11:42:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20D166B02A3; Wed, 6 Jan 2021 11:42:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id 0B92E6B02A0 for ; Wed, 6 Jan 2021 11:42:53 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B907F181AEF1E for ; Wed, 6 Jan 2021 16:42:52 +0000 (UTC) X-FDA: 77675919384.26.waves06_1b0a479274e3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 900AB1804B656 for ; Wed, 6 Jan 2021 16:42:52 +0000 (UTC) X-HE-Tag: waves06_1b0a479274e3 X-Filterd-Recvd-Size: 4733 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Jan 2021 16:42:52 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id x20so7850766lfe.12 for ; Wed, 06 Jan 2021 08:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=utozISaxL63drmUZAC6aSc+ai12dhlJYUKebxiFAYAo=; b=NJgC/VUIvpf5fbTrQst8wZDFHYVt/5v9vItzWgOp62erRY5JkQGsNMvKLDONIPp/BD zfZi6fl4PjIAf6Zmb7/vqYHlqhAebazjLTxpe49ORp+LFKCsUl04l9F1aU1l3EZZwSL7 3C2r0OzvfFvuvUAJEVE08+OI3ztkKPl0RHcNxLSH43zDth8rS2q9Ka97JE1HGgk34A9Y urfd7r+YFlHUazX1lwYuWsVOio3w20BEArpVhHgsEz5f91diI5p1QamKhRnX9eKPmEId K04++Bd9AxG5mDliD9J8T6GMEBG1NZe2MXWAd43BvvvkRi9lRGkmf108ZUt8111O7wJJ DPXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=utozISaxL63drmUZAC6aSc+ai12dhlJYUKebxiFAYAo=; b=bhWCphUGh1UpXg9cZnGEyMVGWNOEOwOpK1iqlv01Y+fV56swGWUDybzBTtZzuY8Qe8 qO/SCkJXtx4Rbj8uGm2v60LU5eomlR6n3YxCjYFZO00+62w08olT4fhbZohRdtsRXfbo GyliTDo+19ajPngRH15x1TNHzgLBGo/WV1ZAXN0czNK1/EDar17q3fQLrXxqYT4OM+PM hNm6mEMZ/U/iOTXoRtvAK/HQTOsz99fQQyu6j4kg1Q8nF4DoBlM6W+NLFI7zS3asYU0P ThJsdJpc5n6QFGpkumPUv5yxcEGb83X9YAC4J08aIB4vYvygffSnYenDXfoxxwXhr7uh ZRtg== X-Gm-Message-State: AOAM533Af5LVjcRTWKdD6e7LE6kvA7Ec4seJh2u3Qc9uryht6TrurfYg GPjl59Co/Es/lNJFC5g7D8KsD94LVR3VTyYLo3t9eA== X-Google-Smtp-Source: ABdhPJz6sko5HMPEfkQrN85i00eLQUoW4zoZJ8FAgB1q4AMuFrWhAoVoO4+B6xGWkCe5D/2dMCk6WPBdue2cAblgRgc= X-Received: by 2002:a2e:9a84:: with SMTP id p4mr2217118lji.160.1609951370229; Wed, 06 Jan 2021 08:42:50 -0800 (PST) MIME-Version: 1.0 References: <20210101023955.250965-1-shakeelb@google.com> <20210106145349.GN13207@dhcp22.suse.cz> In-Reply-To: <20210106145349.GN13207@dhcp22.suse.cz> From: Shakeel Butt Date: Wed, 6 Jan 2021 08:42:39 -0800 Message-ID: Subject: Re: [PATCH] mm: memcg: add swapcache stat for memcg v2 To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Yang Shi , Andrew Morton , Linux MM , Cgroups , LKML Content-Type: text/plain; charset="UTF-8" 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, Jan 6, 2021 at 6:53 AM Michal Hocko wrote: > > On Thu 31-12-20 18:39:55, Shakeel Butt wrote: > > This patch adds swapcache stat for the cgroup v2. The swapcache > > represents the memory that is accounted against both the memory and the > > swap limit of the cgroup. The main motivation behind exposing the > > swapcache stat is for enabling users to gracefully migrate from cgroup > > v1's memsw counter to cgroup v2's memory and swap counters. > > > > Cgroup v1's memsw limit allows users to limit the memory+swap usage of a > > workload but without control on the exact proportion of memory and swap. > > Cgroup v2 provides separate limits for memory and swap which enables > > more control on the exact usage of memory and swap individually for the > > workload. > > > > With some little subtleties, the v1's memsw limit can be switched with > > the sum of the v2's memory and swap limits. However the alternative for > > memsw usage is not yet available in cgroup v2. Exposing per-cgroup > > swapcache stat enables that alternative. Adding the memory usage and > > swap usage and subtracting the swapcache will approximate the memsw > > usage. This will help in the transparent migration of the workloads > > depending on memsw usage and limit to v2' memory and swap counters. > > Could you expand a bit more on why memsw usage is important even in > cgroup v2 land? How are you going to use the approximated value? > Two main benefits. First, it hides the underlying system's swap setup from the applications. Applications with multiple instances running in a datacenter with heterogeneous systems (some have swap and some don't) will keep seeing a consistent view of their usage. Second, most of the applications (at least in our prod) are not really interested in two separate memory and swap usage metrics. A single usage metric is more simple to use and reason about for these applications.