Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3353658pxb; Mon, 25 Jan 2021 13:44:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJx/yooZdUzb1itWO44ANhNUfMCRIU4kwDOaQGtzzyE3bYVe6oP//h+WdpMRrMRf17epHu3x X-Received: by 2002:a17:906:6887:: with SMTP id n7mr1537298ejr.362.1611611097972; Mon, 25 Jan 2021 13:44:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611611097; cv=none; d=google.com; s=arc-20160816; b=AOepghpRYoBEUvjjDeMreMgttnb/MD5xRoBo2eLXn9Dar96n/MzCpx/A694DEGk17G MVVzQsk3b5iFyoszODtGkY5okYxSqkRfWSKFXdYKPVVDKO+heELWVggkupbxk5fV0Gs0 fmpY9h6mI0M1QdT8BWpMMkQN4lIFXdQIjAuvNvqUZium8nOFOsoE61MeNV2DQQGQGxOU v6xy54MYznTdAimJz6siU9DPDZxZ+G0zemYhOl+X1m9J1GZt5o1s1dVgMoUGCfvE3/89 Nvyqf2BM4RkMR6pn1zJC8+smIcEiuRlTYNRU3FSh6XA8gcU3tcxtoikshqx1Trh4cfDF rsSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=M9eTcHg8chZCUECzU0N7RyF6CiCZ9/dNlp0kJLljJGc=; b=StmgRJeR1oY6eWCAZ/yZKU14nbK0o//h1rExsFaizYryqxMHssiIjYsL0CBgAZ8iOl 3pbOhQ4N1lsO1PNmfdQrTNDGnExzQlpaZXd5+dZXAqXIv2dAiL3Lre4Qo9jivIflMUNB WncBksdzX9T9++9rE1WbsbZQiZCEu7rLdP3TJCb0K2fYZDtw19VqENEv7G4GLyIX5Or4 +Hg5kjR1s2UWQQT1hBDBjwFn02r1aQwzzp2gTqZXJDkt9OS25eJ+CvO6HXNkQihXCFxQ x04P/ClnY5O5BOEN+HoYXYJeY9Sqhe4E9s1bSGvNmAB7nJ8ksuMPgspY7EgnEZE8DtN0 PSxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ubeXULCe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f25si6093117edr.468.2021.01.25.13.44.33; Mon, 25 Jan 2021 13:44:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ubeXULCe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732854AbhAYVlt (ORCPT + 99 others); Mon, 25 Jan 2021 16:41:49 -0500 Received: from mail.kernel.org ([198.145.29.99]:36582 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732890AbhAYVjP (ORCPT ); Mon, 25 Jan 2021 16:39:15 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A683E2083E; Mon, 25 Jan 2021 21:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611610714; bh=oBbSa76JFc7v8+y55SX0g1Mr9sPSRsNOv4tmWq7xrRA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ubeXULCeE5ESYXoKbbpQZvbpm7KD3rJtLMZd3bLMpG+Yf8ZlUgaes9e13MakOokA9 iEgnWl6tWG8fgiW+VJGsU1Vz4qkDtXaocuKZT5gFf6r99ZgN3QhYKOTmMnfoGOogzo zlSt15bli+VWxniwjlxtECCstKhhIQyCjc9aSnUV55QlpbsGcamdfknFZPmcXMuxob G02UJe9Qaa5X7Qu+hPXzpNUvjCDYeTaIEq+run7rkZRwSUoqDGVquo06czJpfyCKh6 lYHTox8ewX/SByv9aTWjggJVW9TsgcM9496MPOix7WOWD0WDa1bKzdlfYuPxgdGr6W 86DtTT5jWaIDg== Date: Mon, 25 Jan 2021 23:38:17 +0200 From: Mike Rapoport To: Michal Hocko Cc: 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" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , 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@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt Subject: Re: [PATCH v16 08/11] secretmem: add memcg accounting Message-ID: <20210125213817.GM6332@kernel.org> References: <20210121122723.3446-1-rppt@kernel.org> <20210121122723.3446-9-rppt@kernel.org> <20210125165451.GT827@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210125165451.GT827@dhcp22.suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2021 at 05:54:51PM +0100, Michal Hocko wrote: > On Thu 21-01-21 14:27:20, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Account memory consumed by secretmem to memcg. The accounting is updated > > when the memory is actually allocated and freed. > > What does this mean? That means that the accounting is updated when secretmem does cma_alloc() and cma_relase(). > What are the lifetime rules? Hmm, what do you mean by lifetime rules? > [...] > > > +static int secretmem_account_pages(struct page *page, gfp_t gfp, int order) > > +{ > > + int err; > > + > > + err = memcg_kmem_charge_page(page, gfp, order); > > + if (err) > > + return err; > > + > > + /* > > + * seceremem caches are unreclaimable kernel allocations, so treat > > + * them as unreclaimable slab memory for VM statistics purposes > > + */ > > + mod_lruvec_page_state(page, NR_SLAB_UNRECLAIMABLE_B, > > + PAGE_SIZE << order); > > A lot of memcg accounted memory is not reclaimable. Why do you abuse > SLAB counter when this is not a slab owned memory? Why do you use the > kmem accounting API when __GFP_ACCOUNT should give you the same without > this details? 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. -- Sincerely yours, Mike.