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 2E119E7717D for ; Wed, 11 Dec 2024 16:50:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F7E76B009D; Wed, 11 Dec 2024 11:50:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A7106B009E; Wed, 11 Dec 2024 11:50:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 771E26B009F; Wed, 11 Dec 2024 11:50:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 587476B009D for ; Wed, 11 Dec 2024 11:50:47 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E657E4376B for ; Wed, 11 Dec 2024 16:50:45 +0000 (UTC) X-FDA: 82883266368.25.F33B5A8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 71B2B1C0004 for ; Wed, 11 Dec 2024 16:50:33 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ksqYy2i0; dmarc=none; spf=none (imf18.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=1733935822; a=rsa-sha256; cv=none; b=CgTHV4esVeN3UYp51SAo6wlTNsB64UCJJBW69nrBrG1nJKSoRwVe4ANRtQA5sWKGp6qmAB gsspTZIo22ICgF/BNS14NVWXfTqnzykxeVDsBWuMh9YnLa1pQNI/2g0y+wL5DYFT96sYiI 6fvcjDmtUY0CwmzS5Ho2D8IQNkDFCr8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ksqYy2i0; dmarc=none; spf=none (imf18.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=1733935822; 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=ICuyLC0N1PfoUnP1uyXTx2TzhXrxz7AoS2m8cXy25EM=; b=q4n39voBS1/j5XHfXyLxdQj/lcblDUQETNsaxbl/N/eZQ9KJM4I4dn/MHzENrOdSY29fbe b8h06H9rkrVeEICVvmSLCjn0ww6LLUaI2BWJ7RLbYvp4xFpv/vuNKcmq14Frc+sMZ8tCYr dTuzY67/N4CqNyO1xrhz5nh3wz8sqvc= 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=ICuyLC0N1PfoUnP1uyXTx2TzhXrxz7AoS2m8cXy25EM=; b=ksqYy2i0AI9hb5G2U7wZtdtBix zvF3ABZCd9fRJyw+3zbAaQGChE6id7+DHipte9hiphQ1DNGVPY9tAAs4F87AabenXqEW7v+sn0r+5 IzocDLw2rNMAMxwe0PM7Khs9s0O2mDL/ARsYalvp/WH3kIYZ96D16rNqo/ftE4tNDYjoX37fUBSpf t/uj8qQlqVOoZW82RgYBoQghftna0YQcIsGEZGbyuXfNB+nnFRQyKbNhINPthW1yGPb7DvaUbievo BJUr6HZYNkNzi+2QxztNCA2nsJyaPpCaUcibcD9UEt0rnxsZ6APOtVau7RGhOnHOCr9AliCfYQM9Y yRi1lecQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tLPv6-0000000HDbC-0OZy; Wed, 11 Dec 2024 16:50:40 +0000 Date: Wed, 11 Dec 2024 16:50:39 +0000 From: Matthew Wilcox To: Johannes Weiner Cc: Andrew Morton , Christoph Hellwig , linux-mm@kvack.org, Michal Hocko , Roman Gushchin , Shakeel Butt , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241211160956.GB3136251@cmpxchg.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 71B2B1C0004 X-Stat-Signature: bicamd5ak6wytpn54tyjo4ddzm5gn4kq X-Rspam-User: X-HE-Tag: 1733935833-668559 X-HE-Meta: U2FsdGVkX1/75Jo77C6UisCqQNN5oJh8atHN2+/dhUU440eQHRVry85v/NLa7yTKX4Honpna7qtPEfehFTE9R40PYVnaI6gKv2465EvmbKjWJj0SZyVp0+EHldeIIvMhCpIuovWsiuSFrs5MI9nbQKFjSOfh47/uGRlC++dS3S+yZgLZtFMnD5ckpK1ikls3HiPk3IjZl6NvDgVvMnjkQoTtXjTU+3qrGPpqc7I2oAlqPP7+OcplpK8t0FgwBkiGbI25E1M4por/qyu7qi5d8ugBDZrExRtHAV/OOfqCMymV7NGcZrpsVAiy8J7JCJYufQFDd21JqPFJqgnaZtv1mfjAZforFyQr+XCkprC7jFGmQoDWEtq8mMKHdViZTdC1hAAzbkG8ef85SSGrkN+2rnL3kXeLZ7oQT4tddSpAlehzOd1BjKbTvcari+rozhNkrdu7czMDIAAUEGy6kLsqpwRfepj/x/22953fS2m1Yt9/FYc6HqljVxj1VSTx/YTwd3ZGj0GxZDJuFYFSVsEFY8Wcj5u7GbK4aOhbCsyU2znlw/oH7t/IquMunPLieR7ce+kONxfiDyBzoI/rNUc8ub/UzaY59my+ot5XNOXtOMNHrgvglVopjMhaGoxg7UQheUYBe0sN8rUuCA18KPS4kk3xvjDZNDKaZR3xmGy2qU8bOJqlFSI028LYvEvlOt8vxk7/opcQT36r+3JOozgmIKXbRK8DwpxtVCtZi1UGEmPAQ5l31z2c+jq/BSRkuh1dQ9g4HLzNpTk0iVqM+dqnjHvI23qwZXDxrhfgJ3zE0JGo4TJpzKbrbT3MhIQar6A0TYXeSrMQQyy+cJdtYjUB8yoJh3mNeW9YPp5QpVTyr1kKU+9jEHehk2bH+Qoy9wDBN1qvHpz+6sgQmW+LGyGp34bEZCfCZo8zdpajLKi6WI4MebHOUuEkvHRlI/JeYayEcK4XP6OPlXuZ5FLinM5 e6K+nMiP vx7JYPazek+r4vhlzvjVmXM9YAxRloIsm3wxzxu1aumWVqzB2ylvBVfE5pB7xaUtzW/S4DRG2WXvxNXz/vzwgP7hqmyh416y42ZiegS0TZ6YhzDK/b7vbAQfg54JVg9WJHL0dWiEJMnxXx/pO3ozzIbHZJD33qwVlHM7lbkqkXY+6lLR+XbXkm8KZKA2jEnx4ThKB22KE+xPrhiHM7zntxOmlRc37zcuZsGfDjOMsQ/s6fio= 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 11:09:56AM -0500, Johannes Weiner wrote: > This would work, but it seems somewhat complicated. The atomics in > memcg charging and the vmstat updates are batched, and the per-page > overhead is for the most part cheap per-cpu ops. Not an issue per se. OK, fair enough, I hadn't realised it was a percpu-refcount. Still, we might consume several batches (batch size of 64) when we could do it all in one shot. Perhaps you'd be more persuaded by: (a) If we clear __GFP_ACCOUNT then alloc_pages_bulk() will work, and that's a pretty significant performance win over calling alloc_pages() in a loop. (b) Once we get to memdescs, calling alloc_pages() with __GFP_ACCOUNT set is going to require allocating a memdesc to store the obj_cgroup in, so in the future we'll save an allocation. Your proposed alternative will work and is way less churn. But it's not preparing us for memdescs ;-)