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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4060CC25B75 for ; Thu, 23 May 2024 16:34:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D66F6B0089; Thu, 23 May 2024 12:34:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 785E36B008A; Thu, 23 May 2024 12:34:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6742F6B008C; Thu, 23 May 2024 12:34:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 48DDC6B0089 for ; Thu, 23 May 2024 12:34:39 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0F5791C0C66 for ; Thu, 23 May 2024 16:34:39 +0000 (UTC) X-FDA: 82150209078.20.14175B2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id DDF7B1C000C for ; Thu, 23 May 2024 16:34:35 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kD6t6TuK; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716482076; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pvVUhdkQBWgNG2dQUY6+6EVmXCuxM2RW1Kdkxzfr6rU=; b=F53BXWQo/XKywdbOz87nY/hW73uWR3iA0jcaMWLdvcp0v3V6BaDeI7OqDUInW3C9irYeDH FMYgW5dkX2Tf9Twu4ZpNCO9kz+w6SA1aHmOBBFSu6KgOtiRIQJ2M1d5N6vAnfbQaARKTzo fE14XKVvg86unFZBs5DHN+V3LmDhogI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=kD6t6TuK; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716482076; a=rsa-sha256; cv=none; b=hVu0ltQWd59hVOAZ8IvVGaaGASJjpPokd7ZwafS9vLDNLDCDNAGSAzENPP1oG+DCaKQ1U+ DdP6JUttDIDGGnUzIAghO4ewXvjXcDUMEEm1Aazf9w7wMgBo2PqC1MmuF8VGJ87uGVS/cR 4LASRXRavnHcIywVQgB0+gbpimx5fPc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=pvVUhdkQBWgNG2dQUY6+6EVmXCuxM2RW1Kdkxzfr6rU=; b=kD6t6TuK9Y75pFvCdBUFlcUBUw gUWIBDwCCjdYrQtBskgXS9vKNShsG4zloi8MIXkmzwcDRmbh5a8fvtja3aG8Ymw+JYTjQ+QKFx1HP ej4YPNNzLKgJufJKUxIULd1I/QkRjTb6E6UDHkIxpHPAU2Le7c8qLBOrdjFPyCyRwo3A8JWpTr5wE DCgJ9i+Gev9ZVdk0TkH8192imUGdMH/MNDNtnrVkvIE0K3h6LmzFe7bYnqVEQvajNL0ufCpS9SJO9 e/Qsl8AiOuESKFrRYtn7Cte860f7hLfeGvUeCN1XVPwbJdiUh6eCMrBITdapaixSTm2lrNEJKzJXH ihNPmiWQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sABOd-00000001tV2-1DPa; Thu, 23 May 2024 16:34:27 +0000 Date: Thu, 23 May 2024 17:34:27 +0100 From: Matthew Wilcox To: Shakeel Butt Cc: Kefeng Wang , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes Subject: Re: [PATCH] mm: memcontrol: remove page_memcg() Message-ID: References: <20240521131556.142176-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DDF7B1C000C X-Stat-Signature: hsmwym1dfdqd755nefwto8t4wwn34qr4 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1716482075-213851 X-HE-Meta: U2FsdGVkX19XrJ/FfSxnQL+d6yLNDzX3LX0JKnUVnFcwHaZ8gocjguLgXVzJSj0tAd/zSC3PvD5zq4n4CvcuuEoygRH03p/ayBzUhzFjfdl7bss4P6yj/MZG/f8gMQ5Vh+0duV4lPRNOsnH2D7utw6As9rdYFHOtbLKSWvoeo2H0lhZxakDDykwbu6mXN8+K9bVJjvbX7Whw+a6rK3PaWogqXGb2o0imBC1r+pGbJ67NtkqSYXgAOTfLUyYzHcMO6bIR/CXtpcbuyefkAXGRtBPPCxpvgBD7Rt4E1kzn37FNu3mWd488+F+qcJBkei2ni0H6bQXL/wEVug03jxNuDvI3ZVaHuMqUIXC4ypJFYUqbLE4fJT1FKvYWgVWFvxE7dT2WmUmmXKN9VCOtgSFbMJbYNoWF92+JjOw+qYRRcj3z8FpyqcBRnNW+y48kgiLZkra31GIudfQsR5skJla2kSlW/uSpA5SBhcNgscDZpTN5NsGz6QY5aatvUdX3AUDHv4CDPk3ndj4cHL31fYjg66dL90kNsa6Y9i2A9IS5h3IEDu3Dx268fkO8zw/Z6WQxBLcmHCvg2Fm9wHTUwtAqq9QTSa/DHimwc+7p9vkXkSVPr9xvx/TzB4zGeWR6CKZlZ9m+pVRm+3w6VN3h4yNex55MZcS0CUHnu/1+wjad/n7ZrDgbYj0/iVZBJ0DHYtC841Ir5jXOgW4xTCyxbiuUiJSvV1CswRzfDMwla/DGWWmQs7YfaC6TAqSwtNlTx8uLHipe6BqdZSlqkIWvQB4c+ZFd6b5MxBPHmiAsg+D24BYG+84NJ07cK0ZwoAZ/yeGUNgAAB59RmhI147fVNNAE2gfzICYhMBuLfEPvdyZP4C9kEOmu0AVTDM/gYxXstHeBNlYW37etIq7HjZF8c+UJHCvcNtbhDfj5H49lTwOtuQTiAnAuj4vW561P0ttzC50JvbBVD6hsOJ1rMbNUpHZ 6Jbuo8rG Ue7dRVzl1/jmaUz6AI/oravAiICrZ1lZfEtMT5AgFyrcSP7yN8iVBvMO86G4yqatwqOZhz20f0r9WKlfLC7cn4wzl9+3Y9DjZ8mWdVthRsFnaLz9rPWBVdpppEBzcB/Fd7Hn719w5GMyWjvidre0CgudT+vZiWqrDP6oES59hyD/kVtaeDzIQcjGMvrI8WNWmmVJ6 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: List-Subscribe: List-Unsubscribe: On Thu, May 23, 2024 at 08:41:25AM -0700, Shakeel Butt wrote: > On Thu, May 23, 2024 at 02:31:05PM +0100, Matthew Wilcox wrote: > > On Tue, May 21, 2024 at 12:29:39PM -0700, Shakeel Butt wrote: > > > On Tue, May 21, 2024 at 03:44:21PM +0100, Matthew Wilcox wrote: > > > > The memcg should not be attached to the individual pages that make up a > > > > vmalloc allocation. Rather, it should be managed by the vmalloc > > > > allocation itself. I don't have the knowledge to poke around inside > > > > vmalloc right now, but maybe somebody else could take that on. > > > > > > Are you concerned about accessing just memcg or any field of the > > > sub-page? There are drivers accessing fields of pages allocated through > > > vmalloc. Some details at 3b8000ae185c ("mm/vmalloc: huge vmalloc backing > > > pages should be split rather than compound"). > > > > Thanks for the pointer, and fb_deferred_io_fault() is already on my > > hitlist for abusing struct page. > > > > My primary concern is that we should track the entire allocation as a > > single object rather than tracking each page individually. That means > > assigning the vmalloc allocation to a memcg rather than assigning each > > page to a memcg. It's a lot less overhead to increment the counter once > > per allocation rather than once per page in the allocation! > > > > But secondarily, yes, pages allocated by vmalloc probably don't need > > any per-page state, other than tracking the vmalloc allocation they're > > assigned to. We'll see how that theory turns out. > > I think the tricky part would be vmalloc having pages spanning multiple > nodes which is not an issue for MEMCG_VMALLOC stat but the vmap based > kernel stack (CONFIG_VMAP_STACK) metric NR_KERNEL_STACK_KB cares about > that information. Yes, we'll have to handle mod_lruvec_page_state() differently since that stat is tracked per node. Or we could stop tracking that stat per node. Is it useful to track it per node? Why is it useful to track kernel stacks per node, but not track vmalloc allocations per node?