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.2 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 E11B6C433E6 for ; Thu, 28 Jan 2021 14:57:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5533064DD9 for ; Thu, 28 Jan 2021 14:57:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5533064DD9 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 69F5D6B006C; Thu, 28 Jan 2021 09:57:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 627F66B0070; Thu, 28 Jan 2021 09:57:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F1F56B0072; Thu, 28 Jan 2021 09:57:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id 330216B006C for ; Thu, 28 Jan 2021 09:57:47 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D9E403637 for ; Thu, 28 Jan 2021 14:57:46 +0000 (UTC) X-FDA: 77755488132.15.cork92_3506796275a0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 99B011814B0CC for ; Thu, 28 Jan 2021 14:57:46 +0000 (UTC) X-HE-Tag: cork92_3506796275a0 X-Filterd-Recvd-Size: 9668 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Jan 2021 14:57:44 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id e2so4324800lfj.13 for ; Thu, 28 Jan 2021 06:57:44 -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=6JeWN8a5WUkyxnK36YoF5ECUYQ0YQQyZ8/Qna1NsShQ=; b=As0f3ZjdzvdCwifWZLl1QKfjKa8UOgbj+P2sZklA3JeJHRBFMWu0H5wiflr7/g1HdC 3EjIecN6Px4mzk2ZBILkQfelKQTbnGwSzIocfdSMYIkirHo9CBbLzSIMXutUiAf6vvRc O/x3qpP8hsiEOTbNWqSjQJEQy2deXqGIeKK1Eiy110fgfCnqxwFB41oeOrAJr2xWvT1q RtaTVjDEtI0m7Z5lSQoJRTOt4f3/Vop3rVyNg7HaTwp/ta+UInes3JfxoRBzhApQcJVC zRX0Gbp2enO00BN0CoZKSrEiJpykCEajRuhij0lcxoYUBrveBZExa8KzS9ylf7cYTei3 czvA== 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=6JeWN8a5WUkyxnK36YoF5ECUYQ0YQQyZ8/Qna1NsShQ=; b=GL99ROeV6n6xL3uM9eR5Jr2Uc11TsB3z30kh/hA1CdaQkHvHtjXxQyjhswuP8nVMC5 Vtu84yZ1k0f9FNtJtmlsqKER/KWujylspJhYzW96Wnc5++3jZqCwVFHIjSk7qJc2wFvA gH1B5st/KyQjexIDD+aXtXe/aROE7Eo7DEdl6o4v3C/uuztv0g4GbEdCZnfhrDD8SFFG gbVA6wfaAGdEOHi4hP+QPBQE0by+Thz52qlhaOmq3OGRYgRBr46CkzOZZMS8d8Jg2hZ/ mU7T/VuqFs9/GTC7ME984tCDpST0KCKRFkdHkTY5DEuuyxp6Qw8/zlRkn14ekz9u4Omd 3YDg== X-Gm-Message-State: AOAM532WO3WZedx5xmaCY95jlrKnOKxiEcFfyf+LDS1t/9r9xRkuXEkn u6VReV0Rxuh3xBg5FbDpLCwyd0RLtpwjhEucBv0nOA== X-Google-Smtp-Source: ABdhPJwnMPNGU3TqSk70s7k7l99wJrsKfvMYfSXuKIgpScpKrS2rUc1hXzqqY/mlKLeMfqPqurVK8/4c/RV2TUlC8OE= X-Received: by 2002:ac2:4c26:: with SMTP id u6mr7622497lfq.347.1611845862683; Thu, 28 Jan 2021 06:57:42 -0800 (PST) MIME-Version: 1.0 References: <20210121122723.3446-1-rppt@kernel.org> <20210121122723.3446-9-rppt@kernel.org> <20210125165451.GT827@dhcp22.suse.cz> <20210125213817.GM6332@kernel.org> <20210126144838.GL308988@casper.infradead.org> <20210126150555.GU827@dhcp22.suse.cz> <20210127184213.GA919963@carbon.dhcp.thefacebook.com> In-Reply-To: From: Shakeel Butt Date: Thu, 28 Jan 2021 06:57:31 -0800 Message-ID: Subject: Re: [PATCH v16 08/11] secretmem: add memcg accounting To: Michal Hocko Cc: Roman Gushchin , Matthew Wilcox , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel , Linux MM , LKML , linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt 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 Thu, Jan 28, 2021 at 6:22 AM Michal Hocko wrote: > > On Thu 28-01-21 06:05:11, Shakeel Butt wrote: > > On Wed, Jan 27, 2021 at 11:59 PM Michal Hocko wrote: > > > > > > On Wed 27-01-21 10:42:13, Roman Gushchin wrote: > > > > On Tue, Jan 26, 2021 at 04:05:55PM +0100, Michal Hocko wrote: > > > > > On Tue 26-01-21 14:48:38, Matthew Wilcox wrote: > > > > > > On Mon, Jan 25, 2021 at 11:38:17PM +0200, Mike Rapoport wrote: > > > > > > > I cannot use __GFP_ACCOUNT because cma_alloc() does not use gfp. > > > > > > > Besides, kmem accounting with __GFP_ACCOUNT does not seem > > > > > > > to update stats and there was an explicit request for statistics: > > > > > > > > > > > > > > https://lore.kernel.org/lkml/CALo0P13aq3GsONnZrksZNU9RtfhMsZXGWhK1n=xYJWQizCd4Zw@mail.gmail.com/ > > > > > > > > > > > > > > As for (ab)using NR_SLAB_UNRECLAIMABLE_B, as it was already discussed here: > > > > > > > > > > > > > > https://lore.kernel.org/lkml/20201129172625.GD557259@kernel.org/ > > > > > > > > > > > > > > I think that a dedicated stats counter would be too much at the moment and > > > > > > > NR_SLAB_UNRECLAIMABLE_B is the only explicit stat for unreclaimable memory. > > > > > > > > > > > > That's not true -- Mlocked is also unreclaimable. And doesn't this > > > > > > feel more like mlocked memory than unreclaimable slab? It's also > > > > > > Unevictable, so could be counted there instead. > > > > > > > > > > yes, that is indeed true, except the unreclaimable counter is tracking > > > > > the unevictable LRUs. These pages are not on any LRU and that can cause > > > > > some confusion. Maybe they shouldn't be so special and they should live > > > > > on unevistable LRU and get their stats automagically. > > > > > > > > > > I definitely do agree that this would be a better fit than NR_SLAB > > > > > abuse. But considering that this is somehow even more special than mlock > > > > > then a dedicated counter sounds as even better fit. > > > > > > > > I think it depends on how large these areas will be in practice. > > > > If they will be measured in single or double digits MBs, a separate entry > > > > is hardly a good choice: because of the batching the displayed value > > > > will be in the noise range, plus every new vmstat item adds to the > > > > struct mem_cgroup size. > > > > > > > > If it will be measured in GBs, of course, a separate counter is preferred. > > > > So I'd suggest to go with NR_SLAB (which should have been named NR_KMEM) > > > > as now and conditionally switch to a separate counter later. > > > > > > I really do not think the overall usage matters when it comes to abusing > > > other counters. Changing this in future will be always tricky and there > > > always be our favorite "Can this break userspace" question. Yes we dared > > > to change meaning of some counters but this is not generally possible. > > > Just have a look how accounting shmem as a page cache has turned out > > > being much more tricky than many like. > > > > > > Really if a separate counter is a big deal, for which I do not see any > > > big reason, then this should be accounted as unevictable (as suggested > > > by Matthew) and ideally pages of those mappings should be sitting in the > > > unevictable LRU as well unless there is a strong reason against. > > > > > > > Why not decide based on the movability of these pages? If movable then > > unevictable LRU seems like the right way otherwise NR_SLAB. > > I really do not follow. If the page is unevictable then why movability > matters? My point was if these pages are very much similar to our existing definition of unevictable LRU pages then it makes more sense to account for these pages into unevictable stat. > I also fail to see why NR_SLAB is even considered considering > this is completely outside of slab proper. > > Really what is the point? What are we trying to achieve by stats? Do we > want to know how much secret memory is used because that is an > interesting/important information or do we just want to make some > accounting? > > Just think at it from a practical point of view. I want to know how much > slab memory is used because it can give me an idea whether kernel is > consuming unexpected amount of memory. Now I have to subtract _some_ > number to get that information. Where do I get that some number? > > We have been creative with counters and it tends to kick back much more > often than it helps. > > I really do not want this to turn into an endless bike shed but either > this should be accounted as a general type of memory (unevictable would > be a good fit because that is a userspace memory which is not > reclaimable) or it needs its own counter to tell how much of this > specific type of memory is used for this purpose. > I suggested having a separate counter in the previous version but got shot down based on the not-yet-clear benefit of a separate stat for it. There is also an option to not add new or use existing stat at this moment. As there will be more clear use-cases and usage of secretmem, adding a new stat at that time would be much simpler than changing the definition of existing stats.