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 D5AE2C0018C for ; Wed, 1 Nov 2023 08:08:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A3B36B0161; Wed, 1 Nov 2023 04:08:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62C4A6B0162; Wed, 1 Nov 2023 04:08:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A7376B0163; Wed, 1 Nov 2023 04:08:56 -0400 (EDT) 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 31D726B0161 for ; Wed, 1 Nov 2023 04:08:56 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0B3E21A08B3 for ; Wed, 1 Nov 2023 08:08:56 +0000 (UTC) X-FDA: 81408659472.23.A91064D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 91DEF10000B for ; Wed, 1 Nov 2023 08:08:53 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W6bS+d2S; spf=none (imf14.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698826134; a=rsa-sha256; cv=none; b=57veA6qfpW4HG/m210MDZcwIvNikV7ekQretx/KBB4diPRZm5Y8rHY0+L1E11ePQsEsxHb eOGx1n6gjNah/1DrKit5kclDyHqbvs6cRCvVTsQrSsfH9Le+IdVY6L9LCJSlS2AOqUb2Hp c9QIwtehYAeyioFJatqvlN0uN4vmUxg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W6bS+d2S; spf=none (imf14.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=1698826134; 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=8T95un5x9810G5siaMcDC4RrvGntkHnr7XRJuHONxs8=; b=yRIXWIrML1+5PamtjkbGjt9k2CWdfxAmGCA0KD73DB5+lb6v1LRTXs65GR8sFBG6Yasrmn NEsVKJL2zHHpCwErkyQZC8RjiCiWiB/fgetRxHl7bBvoTWRGEKy2qhswlMmkHks4SrxHgK /H9uvTW7TP04BqW8QxJzwprhijJMevg= 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=8T95un5x9810G5siaMcDC4RrvGntkHnr7XRJuHONxs8=; b=W6bS+d2Sk+Y1jvccBXnxO8hjbJ ptPXcKO3D9xNWT1/HkaMQPPYXLAfsr0HhVK5xD0kZhRBv5iVeCgxqcg0MmqZYlEtZWSuSmPUS8g2Y bCSmZoVIPi1G3vU96UfA3btFjmvwpXHexBEC4a5otLzcmsA6g5oM25JZ7BOHv80VrLl7XYg1KTbAZ 3TWZXoPm2BwtZCReplVLGOgM4WTvI/Eq+qy0dqSL4UU5r8Jx7VDXVXYUQEXdCBy61u27+oRqS/Cwb IUtJSMaMgo5Ct2as7m3JrfqxkTS0Z7Gr4T0z5m1NUTt8wk4l65rROSg5Xy8oBw4qUsHzCVL3cZqca /joQdGoA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qy6HT-00EyvI-86; Wed, 01 Nov 2023 08:08:51 +0000 Date: Wed, 1 Nov 2023 08:08:51 +0000 From: Matthew Wilcox To: "Christoph Lameter (Ampere)" Cc: linux-mm@kvack.org Subject: Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL Message-ID: References: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 91DEF10000B X-Stat-Signature: 77ouinx79r3ifpxfrb7y3rw4cjss9egi X-Rspam-User: X-HE-Tag: 1698826133-685844 X-HE-Meta: U2FsdGVkX18ycHR2NhjEct5bfsraHwiYKaZnhR6TMgUDSB7Cr1eUkDjoPGaCVRqe5RCP6I6iqBMlihV8j7qyixKzE8kUr8vXNB/mGo2ZgPZK0MoTO1DBEmTq9qJyHqBgn02wmio2oTDRYxiubAfFUWC50+Xs2qQhX9+N33qTkwmhW1/Bldkr2txSYPbHoTfphfhFe1QzxYE0YdsXhtmVjuifmztrsgOFktD7mDkSFSmbgZZ6ezmtREFdmbh3CkGa60uXSHFuOW4rLbhtcUS/qDgMQ0g08m105cf5rXfp5YOeqJxcJH2KmbxbYEoHfs1oV0nb3CGRaNl/e40c5LH1Zd/4r2/eId8cidaWbfzKqVg+qXzPnuKswCmOuOQA6XWzBliMuyiTX2lYIerETZsgJGYECcGrAfG3ZQHqB6pdYzYxvlQwyB4Ua8p4Mmi+lBnGpHHCmTCqQvu+YwHYTATeCZxK1/WRI0l00aHzX2o9l+/2KTEK3qx40aSfnv9MNnvjtfzqpVfPO2oiUKa9rcYvWkqcenJlblvQGVtZikw7EpNTi3o6XWkEAGCgKDlyud+bizzfdBzGKuOPEs70Zos/bVAxuASW9NQ+hVxcbninLo1TVeWrdYGzpfx5qUF9ixW5Y8HUxGAaZjhqaZscXxXqiq72UeKzbcy5yHsSe878MilArLTyHEOe0s8quEQ3dNhvlSgIZYk6yQ2T2x8XrqlPjI6tYCOB62F44WDKC1Kr1KXRqYUXz4up9umOOkLnXJ/tB1gaxmq1ocIw2wnWkyaqayPADuGb+6kXnIniWdExMsNKWAuvSAmXZIx+Pa83zNCgq9gozLwONoHLkKGUNLQSlAcplDocWYRFedpalzFnhZ8vdMgN6GcHN9wc80YLs2u5rYyqfCaoMzp3x9IUumRTm7su/LbyvuRoJqSdyrLCfCN/LWFCbV6OAgM2O4UD1bzC314iUkpzjD3FRqJfwuy xdjoYUOq 2fV+pwpSeRYe861MoTnQn+zVzulSPHQjtGmdvWqWTVoDoA/+7+1ytUUu0ON/+aEDysD26ClOIMiYW8OP4PYDp/uLFES1k/Ogn+JeSkeqO/kNie01eqwu1XAmo2JL2lTKwqLGvOmcnpWo4q+VgyljPxKRXm5Z0EBaGl34pGXMcY19igMx1huvV9VocSA== 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, Oct 31, 2023 at 05:13:57PM -0700, Christoph Lameter (Ampere) wrote: > Hi Matthew, > > There is a strange warning on bootup related to folios. Seen it a couple of > times before. Why does this occur? Filesystems generally can't cope with failing to allocate a bufferhead. So the buffer head code sets __GFP_NOFAIL. That's better than trying to implement __GFP_NOFAIL semantics in the fs code, right? > [ 20.878110] Call trace: > [ 20.878111] get_page_from_freelist+0x214/0x17f8 > [ 20.878116] __alloc_pages+0x17c/0xe08 > [ 20.878120] __kmalloc_large_node+0xa0/0x170 > [ 20.878123] __kmalloc_node+0x120/0x1d0 > [ 20.878125] memcg_alloc_slab_cgroups+0x48/0xc0 Oho. It's not buffer's fault, specifically. memcg is allocating its own metadata for the slab. I decree this Not My Fault. > [ 20.878128] memcg_slab_post_alloc_hook+0xa8/0x1c8 > [ 20.878132] kmem_cache_alloc+0x18c/0x338 > [ 20.878135] alloc_buffer_head+0x28/0xa0 > [ 20.878138] folio_alloc_buffers+0xe8/0x1c0 > [ 20.878141] folio_create_empty_buffers+0x2c/0x1e8 > [ 20.878143] folio_create_buffers+0x58/0x80 > [ 20.878145] block_read_full_folio+0x80/0x450 > [ 20.878148] blkdev_read_folio+0x24/0x38 > [ 20.956921] filemap_read_folio+0x60/0x138 > [ 20.956925] do_read_cache_folio+0x180/0x298 > [ 20.965270] read_cache_page+0x24/0x90 > [ 20.965273] __arm64_sys_swapon+0x2e0/0x1208 > [ 20.965277] invoke_syscall+0x78/0x108 > [ 20.965282] el0_svc_common.constprop.0+0x48/0xf0 > [ 20.981702] do_el0_svc+0x24/0x38 > [ 20.993773] el0t_64_sync_handler+0x100/0x130 > [ 20.993776] el0t_64_sync+0x190/0x198 > [ 20.993779] ---[ end trace 0000000000000000 ]--- > [ 20.999972] Adding 999420k swap on /dev/mapper/eng07sys--r113--vg-swap_1. > Priority:-2 extents:1 across:999420k SS > > This is due to > > > > folio_alloc_buffers() setting GFP_NOFAIL: > > > struct buffer_head *folio_alloc_buffers(struct folio *folio, unsigned long > size, > bool retry) > { > struct buffer_head *bh, *head; > gfp_t gfp = GFP_NOFS | __GFP_ACCOUNT; > long offset; > struct mem_cgroup *memcg, *old_memcg; > > if (retry) > gfp |= __GFP_NOFAIL; This isn't new. It was introduced by 640ab98fb362 in 2017. It seems reasonable to be able to kmalloc(512, GFP_NOFAIL). It's the memcg code which is having problems here.