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 C5DEEC54E58 for ; Tue, 12 Mar 2024 20:35:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 594438E0019; Tue, 12 Mar 2024 16:35:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5440F8E0011; Tue, 12 Mar 2024 16:35:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4327F8E0019; Tue, 12 Mar 2024 16:35:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 33E7C8E0011 for ; Tue, 12 Mar 2024 16:35:26 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 09EB780C3B for ; Tue, 12 Mar 2024 20:35:26 +0000 (UTC) X-FDA: 81889542252.06.6790DC9 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf07.hostedemail.com (Postfix) with ESMTP id DC51D40021 for ; Tue, 12 Mar 2024 20:35:22 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=sMCEXAm5; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710275724; 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=Ie4azhdaO7XyuGP1SvLiJCvS/cPbUc5GBchc5hu2vaM=; b=A1AHpS83BNdANM/csQONlLZJC1Dshmd+H07eLmpSKHy1NWRhR/nP3mgdW3A4RYWGCS5T44 qH1fV8DcH84stJ+mkZdLyzZe9sTR8bqBtyg1Tr6dhOPchCYOzLAowlAbAoEoVWUmskm4Eq c0hnhftPxwZ3QH57HIyq9BwPkg6gFtE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710275724; a=rsa-sha256; cv=none; b=SurwJchPyR+IzubhMfJXbCQyc+08t1M0o9D8/bNA8L8uEc684FolrBXxDJowBHX/zlno1c rIGhBYIhr/MVat9Y8dMDdCoFY9LzQhbTBw9DuSU/FRlqqphfpuHXHNjhltLBpiwLnEzsqX oxUKdFAfNXZbhpvivgo9ZuJCNXOcEHE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=sMCEXAm5; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 12 Mar 2024 13:35:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1710275721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ie4azhdaO7XyuGP1SvLiJCvS/cPbUc5GBchc5hu2vaM=; b=sMCEXAm5xCpiFPEB39C6K1DXlo0Ho5H5L+dlH2uLxMvPdEQRsv99r9YtsgCv9WgRZqG4tL VxNUGBPsCa75bzqnUBFcy8TdrLlI57sU+4v6e9SdmPRfHtG+pEdA9/AWeUgtroM6lfBmcw O4nP2IRw0rf+l+2B4fx3Br5iKQE0IwM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Matthew Wilcox Cc: Vlastimil Babka , Linus Torvalds , Josh Poimboeuf , Jeff Layton , Chuck Lever , Kees Cook , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Johannes Weiner , Michal Hocko , Shakeel Butt , Muchun Song , Alexander Viro , Christian Brauner , Jan Kara , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH RFC 1/4] mm, slab: move memcg charging to post-alloc hook Message-ID: References: <20240301-slab-memcg-v1-0-359328a46596@suse.cz> <20240301-slab-memcg-v1-1-359328a46596@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: qssxafofns4jozeao7kei4cgjjozor1u X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DC51D40021 X-Rspam-User: X-HE-Tag: 1710275722-75961 X-HE-Meta: U2FsdGVkX19iGwH3DQRO2JeZgHx7dnIJbydr7CTd9CpciDo5q61ywsonIajAvbnb2BnM8xG6ZEqtnboCdySi4IFKM8edYRFG9D2xyiU1NiAwEy1gO6iyifQ/B1qpDbQrhwFJiIzfJ/CiFy304+pAi8uFG6vElVn72dnduDybYN7IbS5uNwd49b8TzNh+J07SRG4ZaVHnYGt+LO2VIeF/bQv2411OsDQhl20PwGuBW2bMYs2Ig3E0P1hqN2b/junUZJMGnwO6LXV1p/WQ2HocOfzKuK7ow0Gc1Ks7C4XO1JrcKJ5qX3ayyOp903qe4ZOob4PE4MKFqiBWuVmktBQR9cHjUpZEDkeU+YZCORbzioRvdAuh2TuDkmK3LgQ6u1/w9u60ekjd9w2sYp1JDe5Mx2qi6Tl9A8EitUvUhR15ZGh0b0ECaQrbMiI7T8QQRUFKNRm3RdJBYrYa/jNUbdCyrWJQsL7UblikfjRPBYLvR68lB0M4xMOPSyM1pFfI9s/kcs7d30k7ooYgUFSzYoj1IQHKpPqvjP2ape1ed44toqhn7KQKDKb5QMKW3mC0pAI3RzfulthCnfuiv8cFN4wYb3CbzsSbYLBeGqvpCawRN1d9IUV88yDah9m2EJkY3jMCcCM8J+4E54AY7nCstSpgKggXlqCNmBFpWqn6bJy9+sAGOhABlciuFCaqpwX92mt+mkcCTEVSmlnJvoTAOEb5lC6jL7A/bvCeeerj9ppxv2wW8QZqHWZLiX3ba4fPAdyDXt4ML4NyTWr76qoUnfTjGa4qYzVhCisEZf0Ae4mIWBumnBSElbgI9HzNn4TirI+RFSrJIjXmrCg85DX+IbeyVZGZ2wHyTbKwj/TOFsOanYqH85VBUVHXjw== 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 Tue, Mar 12, 2024 at 06:59:37PM +0000, Matthew Wilcox wrote: > On Tue, Mar 12, 2024 at 11:52:46AM -0700, Roman Gushchin wrote: > > On Fri, Mar 01, 2024 at 06:07:08PM +0100, Vlastimil Babka wrote: > > > @@ -1926,71 +1939,51 @@ static bool __memcg_slab_pre_alloc_hook(struct kmem_cache *s, > > > return false; > > > } > > > > > > - if (obj_cgroup_charge(objcg, flags, objects * obj_full_size(s))) > > > + if (obj_cgroup_charge(objcg, flags, size * obj_full_size(s))) > > > return false; > > > > > > - *objcgp = objcg; > > > + for (i = 0; i < size; i++) { > > > + slab = virt_to_slab(p[i]); > > > > Not specific to this change, but I wonder if it makes sense to introduce virt_to_slab() > > variant without any extra checks for this and similar cases, where we know for sure > > that p resides on a slab page. What do you think? > > You'd only save a single test_bit() ... is it really worth doing? > Cache misses are the expensive thing, not instructions. I agree here, unlikely it will produce a significant difference. > And debugging > time: if somehow p[i] becomes not-on-a-slab-anymore, getting a NULL > pointer splat here before we go any further might be worth all the CPU > time wasted doing that test_bit(). Well, Idk if it's a feasible concern here, hard to imagine how p[i] wouldn't belong to a slab page without something like a major memory corruption. Overall I agree it's not a big deal and the current code is fine. Thanks!