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 DF9E6E7717D for ; Wed, 11 Dec 2024 21:08:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45F656B0083; Wed, 11 Dec 2024 16:08:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 410416B0085; Wed, 11 Dec 2024 16:08:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D7796B0089; Wed, 11 Dec 2024 16:08:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0E9826B0083 for ; Wed, 11 Dec 2024 16:08:38 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AB27D16129B for ; Wed, 11 Dec 2024 21:08:37 +0000 (UTC) X-FDA: 82883916318.21.2389D4E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id D2AA2180012 for ; Wed, 11 Dec 2024 21:08:11 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="i/aHBbt/"; dmarc=none; spf=none (imf16.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=1733951305; 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=T8mUFcmECrP/TteQEvTLst+33uFFcr5m63mDPK2C7ag=; b=jnK95W/rng6SSC8s2rmRyaEPPsFLhNfwPZO309bWtk2wUCOiwQv7guetnJi1i8euuzz7Ok bSvQzVawopGlpMwMG0/EnU/zxELM+uIkPQxjd5G7V0kVH+VT6KhTuJNNi/D3Nis/sVoket hjTFgDNrHMK7Hwdoi46ybKqrh1gSXE0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733951305; a=rsa-sha256; cv=none; b=hhJZ4Sm7mZcafqJZlqfriO+nvriM3nwN4gdobJRbZjnyAvuNCwGiP/KAPWYwF7zCBY2cyw 9MhoXGeNYKona6yR1r5eFwOhXOfsgaFuRasdef8niPtAWjtTq8N2RStLGPPyl1sjuR9NFw mgOqJqBHKwUsMgWq+EcEIHlfLJ5R+qM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="i/aHBbt/"; dmarc=none; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org 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=T8mUFcmECrP/TteQEvTLst+33uFFcr5m63mDPK2C7ag=; b=i/aHBbt/A3ipc3S0CUjrXE02Ek NM/36ZwFnHhMum1HqAUvD7xs807eOMn8yDHD1fh18M0pFyfa8NhadZE74kGtjp56SssmS1rtri4aJ Ft0Kfp+SV7O8iEYAOBMf4uc0E9PLIj5kZlg13twWxFBBP521xpz2I6VUY5nkQyq3qG9TMngq0HZ25 WlzHwno1loUFkGG2SUE6TdJa0emkxw5CGfsXpxzT4hyPQjtVfuPT9jLsJVzYPDKKKGRmtjfMrgPh7 dWKwK3aJIr4JtTZ2TkOXLc/rOLayW/C3qYxg44s3fbQrkkupxUxsa3attNbnGxlKDVhsa6JWENx9z XTCoAcDg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tLTwf-00000000v5U-3ApR; Wed, 11 Dec 2024 21:08:33 +0000 Date: Wed, 11 Dec 2024 21:08:33 +0000 From: Matthew Wilcox To: Shakeel Butt Cc: Johannes Weiner , Andrew Morton , Christoph Hellwig , linux-mm@kvack.org, Michal Hocko , Roman Gushchin , Muchun Song , cgroups@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/2] vmalloc: Account memcg per vmalloc Message-ID: References: <20241211043252.3295947-1-willy@infradead.org> <20241211043252.3295947-2-willy@infradead.org> <20241211160956.GB3136251@cmpxchg.org> <3bgedgrbu73dovgcy2keqjud6jafqxenceihtyre2hkego7oyb@opc5u53jef5a> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bgedgrbu73dovgcy2keqjud6jafqxenceihtyre2hkego7oyb@opc5u53jef5a> X-Stat-Signature: xhkx5y1j9yptpcgq7eep5nr83ic969c3 X-Rspamd-Queue-Id: D2AA2180012 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733951291-447845 X-HE-Meta: U2FsdGVkX19eg0W516sGtDC/9JiRQcxcdPdELv8FCk58p5JjU5ARBU4G6O1N7alZjpAAu3vdHydgMqDKis76iwH3fA1r4VFk2/FArgD1b9Sd38X6ljaQ92dgt8GNHsd228WcGoS8Bhg8Kf+/nuK8iJC0FZrHK+glYgU5tLPPPMntP2Q67R4ceX4NrB89INCm9f0ORHEb/5ll1Xs6VXmQiSlM6WLFDayOOoOVrNZmICVvzzhKrSNJncOw48Ih8l0ZG7r80JkZys1Wmrkyhby9ABvRuYWoExbWFAZMJa04AxgVXBi8gBzbSNeYeNQyN5JzmX3QBEk9xQo0wjyny3fsGqu2mh2mBak4M/JOyViHOJIeP1l5HzxUUJLkcD1o3lxsRjrzo6y4YV/NDh8llkQFZiKHWUnmnivk5mvOTlM7WP/zyHCEoGWEMnDd981bk7MfYgnVuCRlcTJMXTLhxubolE6MhJ/1m5+XOvYENNbnrr/SRTVd/KoDRDR0Z30efukF8raHCpJjrq1xLwQaa7uN97Jgu63EGUJTW9W6b69e7cwQO38jewCOjNzSI7N7tN9e6GIAPamz0KiZNThQKOjvmubLsALbxZBB7gKcH3uJ+x2gV3rzqQQ3vaW2MJ4onra9RvwobrKH1+im+c1xmUqS+VemYhNsWm8GjgdlNal2phtabNu92TZv5K0aVJeODAVK4gh2pOMyBXFy+u0g3xqryaivIPAguXwMJKtY4zgzEADu5mAXCJ2Ks0Vjcs4L9DcGOO9hDrB1DN59FXw3SpmCG6dYIfM7pGIC7w3dzpFqcNFlwFnds5dfBsnWnYChV8tfXhiLzoAIsyhlwycMGXeyZYmzdd9eGrIRAZ01gbBvHFS49JTQwW+iKp+hGODYMJcLQHx2eqtCMahPrZ4S0fY6ZsNSm5lz65wlSCGnk6eOkfMZWaJ1xlGgTxnIfGuDOCct85UcYcgCl2afVre/jkV bmofqZ7u 4x6zdFxhDV2e2IqzYvRntYrZNYiGmkZUfhVx7IWi+wZGBLvNZ9zsuXeB8ylq25e7z/xH2qXv8ko4fJS4eVunm1xSjlOGsWahylOreQvagrYp0WO1pHTsbDQnr55Y0oVuM+gWHJco3Ef5BqORtswjwycVS+cAW1h+CzNVDUimKstn+xZxGoJyLf7pbLh4ENg5utZHiBmlzmU84J7M4YDkzn7yH3VZEMcv8qJt+ydQSOPffqz83AmmgAxVZLZBiYWg6uimdBLdI6fx0vby4G4gs0kxZHN55BRzEHVRqPywNflT0sAK3ClHzqENgTw== 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 Wed, Dec 11, 2024 at 12:58:36PM -0800, Shakeel Butt wrote: > On Wed, Dec 11, 2024 at 08:20:36PM +0000, Matthew Wilcox wrote: > > Umm, I don't think you know which vmalloc allocation a page came from > > today? I've sent patches to add that information before, but they were > > rejected. > > Do you have a link handy for that discussion? It's not really relevant any more ... https://lore.kernel.org/linux-mm/20180518194519.3820-18-willy@infradead.org/ and subsequent discussion: https://lore.kernel.org/linux-mm/20180611121129.GB12912@bombadil.infradead.org/ It all predates memdesc. > Yes you are correct. At the moment it is a guesswork and exhaustive > search into multiple sources. At least I should be able to narrow it down somewhat if we have a PGTY_vmalloc. > > I actually want to improve this, without adding additional overhead. > > What I'm working on right now (before I got waylaid by this bug) is: > > > > +struct choir { > > + struct kref refcount; > > + unsigned int nr; > > + struct page *pages[] __counted_by(nr); > > +}; > > > > and rewriting vmalloc to be based on choirs instead of its own pages. > > One thing I've come to realise today is that the obj_cgroup pointer > > needs to be in the choir and not in the vm_struct so that we uncharge the > > allocation when the choir refcount drops to 0, not when the allocation > > is unmapped. > > What/who else can take a reference on a choir? The first user is remap_vmalloc_range() which today takes a mapcount+refcount on the page underlying the vmalloc inside vm_insert_page(). But I see choirs being useful more widely; for example in the XFS buffer cache (which wouldn't be mappable to userspace). They might even be the right approach for zswap, replacing zpdesc. Haven't looked into that in enough detail yet.