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 AC164C4332F for ; Fri, 10 Nov 2023 13:38:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5FE78D0007; Fri, 10 Nov 2023 08:38:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D10498D0006; Fri, 10 Nov 2023 08:38:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD7C58D0007; Fri, 10 Nov 2023 08:38:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A5FC68D0006 for ; Fri, 10 Nov 2023 08:38:34 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7C4D91A031E for ; Fri, 10 Nov 2023 13:38:34 +0000 (UTC) X-FDA: 81442149348.10.CD64A67 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id D1A904001E for ; Fri, 10 Nov 2023 13:38:30 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SfvB3xxN; dmarc=none; spf=none (imf27.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=1699623513; 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=TTNpV4MmJIDAMXU9x7+Pc6lTiEp2NJWFNRg9FN/6NMk=; b=yHkyniovgt97IODwEFcmU4KjW7lLuhFBkZxyG4dECdqIRJjifkKnmfgEyOmdHSc3ogUCxO EGru/gfi25hw1d34EdqGtpW2Or6T7UsM2WyEdrJdDcW2W+2GkM92oEVn0LOxxKg7igc5Ic gLTpfRyZMoke0hW1b1kjGn1Qf8+X7Jg= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=SfvB3xxN; dmarc=none; spf=none (imf27.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=1699623513; a=rsa-sha256; cv=none; b=eZu1d9BTSwQHUZy0CgTgMRVaKfvKApQWserBBZUdDgqYNorfApjo8KKl8RNw7nPMSKJ8oR 5DkIQIZmvRtJYE97MrpZZ2mpiJ0ofL1ZJNK8OUvNr4C6Ey95NI+6NgHIs1yGkXwNaZ0wIj ud8uie15pwryjGia2FdkPlSw8fjIfCs= 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=TTNpV4MmJIDAMXU9x7+Pc6lTiEp2NJWFNRg9FN/6NMk=; b=SfvB3xxNmRd8ZpaqpoyDazr9ze EDUJmLvSbW2G5VvbebHbcI7vzaYJ7DFGnpuHtmFtYaoDdDO80x6V8NBL0YYHASv5dYfacTfns8Cuj omekTUEUlmIDpJvmD0IKt8obPcHVvz04n9G8dbKZKC1PNQggvwIvtMrxnjELqTuTazrn1vNI8f0uJ 6TqEdeM5TuxbsyKyn9KxBkv8ywj6LVJMmN6ZK8ilwA8vluLK0vXHumItsGCcOR7xmkLqQB+w5dUJ6 sZtoWuol/JwDyKZLR4FGBcQF3Mq6welUsSZnLvl9GRj0FotQVoyF+TjB+Il9Z8J8B9FTxIl5LIyp6 LIDSMobg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r1RiM-00Dgy4-6l; Fri, 10 Nov 2023 13:38:26 +0000 Date: Fri, 10 Nov 2023 13:38:26 +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: X-Rspamd-Queue-Id: D1A904001E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: oqtghzekh4a1r4tfmwjrew3io9rnpt6h X-HE-Tag: 1699623510-699489 X-HE-Meta: U2FsdGVkX18oVAyUEfzFCqroMbB83KEGWrrtNU9lvinmCOSKmrlf1+8mU11EkLGVi26EfVspdg8yBRaHVo9LHhCT1rYObEoAmTe6xPl9PIm0mkcv22rIRVzgqiRlctJxhQz4IroN/SJ13q1USvDQPx+uO/vJf2XxOFJ6z79T+H6gm0hMu97jarIZcCq8HsNYSvLI4p5o510CEsCfcZacVi2I7T41pvCDYu98nM63KWBU/NZ+8wJoTjg+cfdb/Na2vIwX7ikWnAaSbOJqOWY8GsBCSpCaeuN2XMoeQIO4OnVBcwlAF6QNMOZ1q3ohumBit2rhxwDBPthLcd/I/tmPsbASSb/HIQY23Uba+wgap/zNG4snEKoIEZ9GDyoaZl3VM5mXFt/l433wdJDl/llCIkllW1GuRR0g0BC87IbY4PscJXj4OghjqXCa0GrxtG3xRvvWW3OuigfCC2+aI/zrn4rvfuDAHgmkwCNWmnrw3pFpKBDGLwfIYXmKXf4t/PUGt2JwPm7EQPMX5UvaZMejd0sQCzh0Vf9Gddkh/3dNbrDROMTBgvb+9QbVPuEMrSBrKGFuFu2J5s7EwnYWDpyKS3HNjixpXxuzjrj3MwQ1gzSFpR+1UrxDudawe+33i8TAmS6XXc193x49Ma81HnxiSZDpqTtKBVnIeuBjsHdaihVBbWHj1eybMhP6FV5fH3X14Z3jJnl/UJ8dfyY0yCeSXLX8Hza25UQKKgH2FHJ+/zNaAijmfuXVBzrMkTYDpkS4XfJiac0JUm2Ho6vxHGK62MVnlKwSTrPVltHJJgrXyTWLCOuO6HUjhHQ1gzjBqGGbqGmZGNQ/t4ZVCF9NflyUMXEEQDsEdfz+Cd/JWZJSoVpFxZJYdZOPVkiYTUnBguv22/quqODAFKcycw+q5B3kzedsF0bQvRyL7uquAKQAYwwazG27mzbLvoiQfKwhPNJsY43ZKDfEPU31Qn+Yqpl Ff26N0tM jGy9Y/Dc0mZ36RYskrytZBsrgSomxJwUIORelKJSpY+2mq+505MaOqolfkgh0k2pic39EWx241wV84CrVJKET4xfM5IW5ukmZfdQwa9fWCAT+3udXXKrypiSI9jcyvlwd9venhvUK1K1hrjm3oKzbqPdItx/o8hZJA4z+0HdG8DGRpLTLtCh1j7+dPQ== 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 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? Christoph?