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 61E93C4332F for ; Tue, 7 Nov 2023 19:24:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E69928D0054; Tue, 7 Nov 2023 14:24:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E19798D0001; Tue, 7 Nov 2023 14:24:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D08578D0054; Tue, 7 Nov 2023 14:24:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C19928D0001 for ; Tue, 7 Nov 2023 14:24:23 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9B6D31CB5B3 for ; Tue, 7 Nov 2023 19:24:23 +0000 (UTC) X-FDA: 81432134406.19.DF6FACF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id 5F0F980011 for ; Tue, 7 Nov 2023 19:24:20 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F2HmsipP; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699385062; 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=opjEIOO1JtV8yJtGuc5p2oYazK/CNCamWHwO2FoBiX8=; b=OxxwenJSFIZCMQ3m3morN43PC6XLH4GSFPZMg8Er0ZD32y22fc4lHzQEojVCZNtWNvDTBc p+RIwqJWCVHlfFdYSzDVY7ar//lLNtek+GEMcudiwne/J5LqTE6nkcBXXRBRgBxywWuO8T fii6S8Fv4qTX02c/QpArGPRb34Wz6w8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699385062; a=rsa-sha256; cv=none; b=YUnXx8rcS01sE9bHpiZcElgZlAcJShqzamJNlKUZgcDCZhBZZcHQ7z0u+Yzd1sWssnkBwR x8vlbbujSlL1gY30+bIVJRs7fOj+7btgCntYekk21+xxQHkc9J9TbUB6PNlk2ODX8+KHkR U3wEDuRJFvf8pfuFgSE4x82hFrnYeMA= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F2HmsipP; spf=none (imf30.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=opjEIOO1JtV8yJtGuc5p2oYazK/CNCamWHwO2FoBiX8=; b=F2HmsipPR+qrkejgPJnJv/+tDm cGr6EdIgTJi6fR1jetdoXowD0R9/jTkAtEd28Kjzt5L3SxxmREbMRFLLRA8a1x82O7tFtn1P7pp+1 AKcsNPri9tmUDRN12LNnOCS0uruErxp/c/Qt+cvX0Su/TJpCasgIM6ode9Mf3LcbQc3dtYsqeebOP efMdLtR0wOChZwz925qTnLvWE8t4MibqT81yadQxCYLWoECLGb8yd0UN3KaLHZaq9SJ1/TH1AJRXw vONOiTqvfxahfkZ97qA583yRdLT+8B/iWiXZQT+kkp8whPkNbRy3nCuJWA5GsqKFNsnYB3gsmzFa5 CJcJTK+Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r0RgG-00E6ld-Qe; Tue, 07 Nov 2023 19:24:08 +0000 Date: Tue, 7 Nov 2023 19:24:08 +0000 From: Matthew Wilcox To: Christoph Lameter Cc: Roman Gushchin , 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: <8f6d3d89-3632-01a8-80b8-6a788a4ba7a8@linux.com> X-Rspamd-Queue-Id: 5F0F980011 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: e81cfg4jfc5ufpubb6bsxbiw1rkpdndw X-HE-Tag: 1699385060-246095 X-HE-Meta: U2FsdGVkX1+feZQXRZVpEmu3Lqq/GmzQ3lRrxWUtoNT7oFmShRVBQOHiNF8Mq3ioEfo1Ppo+jps/P5+5TEf9x0i8Ejnd5cpW9JiSuFy9DGb0coLYAf4ThM1b4JIpDzuCvHjIiI3u8AbllXpP/QV4lGiZ53HTr5Ug665L7LMlPK++E8IvqB4FvXf39yjI9J5hiArIuHl/2r/CJHT1GmCqm7sNXseUvLfYFIhYgtfJisBniOVOoYjTchPGMYUdzQOIoBubBmruRf/yl5MYYRR98qMv9cBKjgf++eg8rpjjeNhpbBEhAEl/yC5OPfYci43bX0oH8q0JHZ95qGJmRgDYOyWreVu7r9CeXfuJco5RTwq6xR/FVsCihIvMusJfv1VGrcR5h4n95bx+zc13edmqM8jc2ht4wkx3JVBkkulBE08HnkNoUHUKx63gfqHLGqhxedVHZLoVFUzCXezCMsZoRgtNg7gA0RihH+qnqZKteqJOahVCeom8y28Iw0+NAXCPacFVpXakxsyFxX6FGsFvOki9yEpAq2jyrsdq5+c8NVKJXlrYLdRbrc2jORbYMXGLgq45v/l7D709zgEOpv7naD5Uy1lskQH6wKz8fFgE8wbmux5PK3wT15lsQe9pvMn6sVChT53uikQ/sy00daYO7V4H8OLrSEoWBmeyeQTmRwtIvg5YfvanrXd/TKjF4YHNTHJoAmFVrpT9Zrsm+Qfp1+iGiDSCQidUyAV5CKnNSENI2uQhrK/EZ3LtAtXWK4ZXkRnwo+ocP9Rnll/8F7DWSEq/p+DlEUZWJlOmjztZ3PLZqCMqx/BQRRt7cHaOc7OmMHuOUSxjlN5i0bQ+CSTbPd4U43/ZU1DyVzOED+3WCCjvTPFJRoD9UWR7qLAvfnhSqvkO3DrRCS7xaHTM25yw7Rre/DiDWpLa4yscsfHRJnUDadDz2wsMZ71uDJODQ4REL9arDlit+/eoWRWoBjO pwymJ2Qr vfVI4tSqIrlUOI9cnlQ0pg4SDcahOhBDzK3giHibtSSJh3igOE/DNRtb1uzgakOTBoKM5TIuFQT64CJ+83AbHgd12xnm7a7TP0xiCfWmdO7+5DYPi5OuxZsqjBO20HFdfkx09RBjgB87L3mQo6LZZP1k0peJ5lNLH6CpxnyL8DXeKqe8fK0sbRqSWDg== 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 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?