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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,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 738B1C352AA for ; Wed, 2 Oct 2019 13:00:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 18B4520842 for ; Wed, 2 Oct 2019 13:00:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GXDNtZP2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18B4520842 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 7AA9F6B0005; Wed, 2 Oct 2019 09:00:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77F6B6B0006; Wed, 2 Oct 2019 09:00:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 695A06B0007; Wed, 2 Oct 2019 09:00:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 48EDC6B0005 for ; Wed, 2 Oct 2019 09:00:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id CF0E0814A for ; Wed, 2 Oct 2019 13:00:20 +0000 (UTC) X-FDA: 75998853000.08.map79_2013de2401b43 X-HE-Tag: map79_2013de2401b43 X-Filterd-Recvd-Size: 5124 Received: from mail-yw1-f65.google.com (mail-yw1-f65.google.com [209.85.161.65]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Oct 2019 13:00:20 +0000 (UTC) Received: by mail-yw1-f65.google.com with SMTP id m7so1913394ywe.4 for ; Wed, 02 Oct 2019 06:00:20 -0700 (PDT) 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:content-transfer-encoding; bh=7MxrKuI5sPe4orcfFy2pIM27MTW0kfpe0fT8luuNjM4=; b=GXDNtZP2zjopSwjq0nyxQ5XSQ5zGN38LpZib81E3XoR1dL9OW17mrq7PEoZhW+LAcU EhuerB9ZdlFoKPdqXPMxy9S7Hx6bEtL723TN9APpkthiTTPwLhcVwrq5mDjypyDve0hd ads9QQUqzHFd22hABBj+VClQ/PjWF6BeW/qrm1WN7lTpJ9z5KIL3A6p/F5XRCCEt2TuJ rcIGaE8iznAR0nYG9XeRpiBVR1+6Tm+ISFiCmuXVgi+OraSqJyHJPIEH2gFdXEbuMDrS PBGQ3Zgqv7pc3DdgPORlw+3gfRE8ikBnLNurksJeaAuFVM21wy5eKbOOIV/tcFB6we25 N6DA== 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:content-transfer-encoding; bh=7MxrKuI5sPe4orcfFy2pIM27MTW0kfpe0fT8luuNjM4=; b=fpoW3PlBkLTHMPzKWIogqeKeKsJkBygxNw0ZCO/voee9w6d26mP7eyacib/r+LvFHj e4ROdKJug+GpVHBlK4SUFz0cmMQ70+tO2DuGJu9FHX5cF8qcCB/V8jL73yuwxKhe11dp U252ydC28CgVMahHSjgB8PySlAvZjOkWCi5GfZBCDbxrkXPQmkk46XD0OUgD0n/lNHqP Ismutnc9A7jKkomczPdb4txYhW93n08kGizGoHpWwcOne5iP/WwDew7qU//D28dD1toz AAswWAfSg5iR17xqmSXNfPf8Il9ALrzAEUgyyx71I+5d67itZK4hvNxblZd/PpId96wj CFnA== X-Gm-Message-State: APjAAAUfs9OA/0vJ/s54bBQMgE7qlleKpM350EOKTmqTgTV6a+e7LdjO Z8I0MuFzZjlGfGh/aIWB7O/kGWrp6YCw1k6ckw845A== X-Google-Smtp-Source: APXvYqzR7JQn1ndsqASj0leEIvy9DfGHuMILlcQ8HgYMNL5BSQ5MAUFSHVCs0BGJ63vyGGkLWxswGdtyfzCUo0H5MTI= X-Received: by 2002:a81:92c8:: with SMTP id j191mr2566314ywg.57.1570021219382; Wed, 02 Oct 2019 06:00:19 -0700 (PDT) MIME-Version: 1.0 References: <20190905214553.1643060-1-guro@fb.com> <20191001151202.GA6678@blackbody.suse.cz> <20191002020906.GB6436@castle.dhcp.thefacebook.com> In-Reply-To: <20191002020906.GB6436@castle.dhcp.thefacebook.com> From: Suleiman Souhlal Date: Wed, 2 Oct 2019 22:00:07 +0900 Message-ID: Subject: Re: [PATCH RFC 00/14] The new slab memory controller To: Roman Gushchin Cc: =?UTF-8?Q?Michal_Koutn=C3=BD?= , "linux-mm@kvack.org" , Michal Hocko , Johannes Weiner , "linux-kernel@vger.kernel.org" , Kernel Team , Shakeel Butt , Vladimir Davydov , Waiman Long Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Oct 2, 2019 at 11:09 AM Roman Gushchin wrote: > > On Tue, Oct 01, 2019 at 05:12:02PM +0200, Michal Koutn=C3=BD wrote: > > On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin = wrote: > > > Roman Gushchin (14): > > > [...] > > > mm: memcg/slab: use one set of kmem_caches for all memory cgroups > > From that commit's message: > > > > > 6) obsoletes kmem.slabinfo cgroup v1 interface file, as there are > > > no per-memcg kmem_caches anymore (empty output is printed) > > > > The empty file means no allocations took place in the particular cgroup= . > > I find this quite a surprising change for consumers of these stats. > > > > I understand obtaining the same data efficiently from the proposed > > structures is difficult, however, such a change should be avoided. (In > > my understanding, obsoleted file ~ not available in v2, however, it > > should not disappear from v1.) > > Well, my assumption is that nobody is using this file for anything except > debugging purposes (I might be wrong, if somebody has an automation based > on it, please, let me know). A number of allocations of each type per mem= ory > cgroup is definitely a useful debug information, but currently it barely = works > (displayed numbers show mostly the number of allocated pages, not the num= ber > of active objects). We can support it, but it comes with the price, and > most users don't really need it. So I don't think it worth it to make all > allocations slower just to keep some debug interface working for some > cgroup v1 users. Do you have examples when it's really useful and worth > extra cpu cost? > > Unfortunately, we can't enable it conditionally, as a user can switch > between cgroup v1 and cgroup v2 memory controllers dynamically. kmem.slabinfo has been absolutely invaluable for debugging, in my experienc= e. I am however not aware of any automation based on it. Maybe it might be worth adding it to cgroup v2 and have a CONFIG option to enable it? -- Suleiman