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 C5F63C4332F for ; Tue, 7 Nov 2023 21:37:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 336BB8D005C; Tue, 7 Nov 2023 16:37:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BDDC8D0001; Tue, 7 Nov 2023 16:37:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15F698D005C; Tue, 7 Nov 2023 16:37:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 01C628D0001 for ; Tue, 7 Nov 2023 16:37:27 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D37F3A0B53 for ; Tue, 7 Nov 2023 21:37:27 +0000 (UTC) X-FDA: 81432469734.12.CD944BC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 9149940002 for ; Tue, 7 Nov 2023 21:37:24 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rg7+BIxF; dmarc=none; spf=none (imf17.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=1699393046; 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=VZKUcrpeKgdBxyuhSqTuuXcGg2taSZU47KZRc+Dw/ow=; b=nByaqIUaPh/DCh1gw/KuQmOEam4Hbxts4zJh9tFG4Ve/E5cmuyswnZkWD+RNjQfNp6EjRK KF/SxjLnEbs8vfePAqGzGdVJxmo/dutV6fp4rGkRWwe15YInLRe2Yoco94EoZklp/CUlhx NuwQBRnCg9E5Dsh1VmjWF6Kykq5O63o= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rg7+BIxF; dmarc=none; spf=none (imf17.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=1699393046; a=rsa-sha256; cv=none; b=JuneJyuVlIeER5fFsKJlJtIwyvQ+DaK1kWy1TSFxuPyr3nYILMCdakxPKaHOFr5ruq/RC1 Kc8fDJMdnRGdS5E9YuYphZBlBGrwatwUNaQRn6AS1wwgTNbq8MQ9S0AZlGYriO6+RhgqA8 6IlMtsXQ/ScGxhKWWN2PUyryximsyEU= 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=VZKUcrpeKgdBxyuhSqTuuXcGg2taSZU47KZRc+Dw/ow=; b=rg7+BIxFt5omB6LPXtqz7QwIdV dVQ5SZBNQU/dRXHPQqz4bqUfbyJJEaGdhx++NgCtHDQ0tqOfAyZWTjMzbXTn7LqBLK/W+VoSSdR4M Nz/dnyKOu9Y84MK0RKcxjK1AziewW0cG3R5UEOeZE31cmWfImzywREEZFsN72F+OmiGtVHOAk0OBM xeFY0rjkC1qTFTXX61AUWg/Nd9cZ+6fOK2nD8kSJ2QPTfjhWCPyecw0RyvER7yhEFB6QpmviQ6QjM ayKiTqW+Km+jkI9VFQ04XIPjTcBxHbtAu08/ZR8/OAtRJBkuh1kQ6NT3RH17pH6P7mL4XgaICHcMW PqhVlqig==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r0Tl7-00Egjh-MS; Tue, 07 Nov 2023 21:37:17 +0000 Date: Tue, 7 Nov 2023 21:37:17 +0000 From: Matthew Wilcox To: Roman Gushchin Cc: Christoph Lameter , linux-mm@kvack.org, cgroups@vger.kernel.org Subject: Re: cgroups: warning for metadata allocation with GFP_NOFAIL (was Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL) Message-ID: References: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org> <8f6d3d89-3632-01a8-80b8-6a788a4ba7a8@linux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 9149940002 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 4nkma4iamxd1s6a63echo1gbzji6tdyk X-HE-Tag: 1699393044-944748 X-HE-Meta: U2FsdGVkX1/se1KXDQisZlffanpw5VPmEf8i274pCnAkykxzZJgmNq/ShnINU0BWeFEODBFOYPYYtC5E1F34bC+LWIXPT1UT1mOmEQpTktYuOIGd8nIR1463Q7TrqbxxZaTVbSXym3oDBrPMKieZ3esvYJrpvD9W6gNdNUzfk0JzKbt552rmjmGOAEI5cF1XShOi7BBu9SM66MLyn1LLZo0aCuCFahbRCjmt+QvIh0njd38W8IAZsWKrzATlfAkOeiFD0hMq6dbS3uAmNl8PLgV9NfYs9Qn4nX6hLTaBSOGUCWbJJ8xj1XSUnD/L6+K5qXmI5MD7WfnlaUp7BzooIBA6w2lArOdRWjrbW4rYxD0oCBit05Uefv1hbPLe2TKAFyRJFm2tl/OCQJr7SiYXIxaS5ExR+KfvRBIRiFtR1Fac7c8O6ETQG1HT2yWtwNKB9+NO46rZcZR/q8SGSq9Nw6x5gUmOubVQgKl/OQfhG4FlVB1REyFcAVZO/2sqnKuv124VVY8M+juHyYO2ZqhIxthnMWmO3olCIHRh+7GoglDs0szKN0Q3t/Tkra3S7r1N5X7hnUvjpdJC1WwC6hx9hf5jo7SKJfZP7E+pk8L4fjV6e+nypyWacu3nLQMajifLPvQ+LdFw7uOF1XisLmj8rbi8qXCRTt0kxNE5UqB4+ZT5hjGg5IN75L7oHqQU53xXF9439iT0uJGtr8FXs58+vpo0RItUG3Dg6pMwGLdAiqANHoIYAhvkURfBrvrAVJ26L8HnEusCCZ84VSQCfnRw+qhno73jziFzGpWn1qQsSePnCv5TEIGzIvdnhjcDQGYz8lKYyw6SMuvMRXGtf63U0YPrLjLA8MLns4ruyQSiHkuyQPT+tXXr6Mjq0TbMiygUvNPUL1TuLFjFYiLHygSiRA4OYCwrru6GO24fTkAj3rGTb/QP7duL9EL4oQP61BkTFcoeubtE+8eF0yb5kZG mTaM7KFK fSMKIUSq35FThalZvrHjg9F/R75C9099hTMNmsteGzRYAZDhu+c2zqMTEseHZZQQDddYp9M5qrdXUi1NBioocaChM/6kMgpFBJXFkkmNe//Ph/O+HHtbURolnZ4B7kRxfXuY3LplElFkPSN4D3y5ZSNdXJ+Zc812IaZvUIMN5/V1PjaNVQgvsR4NMeg== 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, Nov 07, 2023 at 01:33:41PM -0800, Roman Gushchin wrote: > On Tue, Nov 07, 2023 at 07:24:08PM +0000, Matthew Wilcox wrote: > > On Mon, Nov 06, 2023 at 06:57:05PM -0800, Christoph Lameter wrote: > > > Right.. Well lets add the cgoup folks to this. > > > > > > The code that simply uses the GFP_NOFAIL to allocate cgroup metadata using > > > an order > 1: > > > > > > int memcg_alloc_slab_cgroups(struct slab *slab, struct kmem_cache *s, > > > gfp_t gfp, bool new_slab) > > > { > > > unsigned int objects = objs_per_slab(s, slab); > > > unsigned long memcg_data; > > > void *vec; > > > > > > gfp &= ~OBJCGS_CLEAR_MASK; > > > vec = kcalloc_node(objects, sizeof(struct obj_cgroup *), gfp, > > > slab_nid(slab)); > > > > But, but but, why does this incur an allocation larger than PAGE_SIZE? > > > > sizeof(void *) is 8. We have N objects allocated from the slab. I > > happen to know this is used for buffer_head, so: > > > > buffer_head 1369 1560 104 39 1 : tunables 0 0 0 : slabdata 40 40 0 > > > > we get 39 objects per slab. and we're only allocating one page per slab. > > 39 * 8 is only 312. > > > > Maybe Christoph is playing with min_slab_order or something, so we're > > getting 8 pages per slab. That's still only 2496 bytes. Why are we > > calling into the large kmalloc path? What's really going on here? > > Good question and I *guess* it's something related to Christoph's hardware > (64k pages or something like this) - otherwise we would see it sooner. I was wondering about that, and obviously it'd make N scale up. But then, we'd be able to fit more pointers in a page too. At the ed of the day, 8 < 104. Even if we go to order-3, 64 < 104. If Christoph is playing with min_slab_order=4, we'd see it ... but that's a really big change, and I don't think it would justify this patch, let alone cc'ing stable.