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 07352C4332F for ; Tue, 7 Nov 2023 02:57:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76BD76B0199; Mon, 6 Nov 2023 21:57:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 71C726B01F6; Mon, 6 Nov 2023 21:57:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60AFF6B01F7; Mon, 6 Nov 2023 21:57:08 -0500 (EST) 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 5081E6B0199 for ; Mon, 6 Nov 2023 21:57:08 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1F1D640999 for ; Tue, 7 Nov 2023 02:57:08 +0000 (UTC) X-FDA: 81429646536.12.C283181 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf03.hostedemail.com (Postfix) with ESMTP id 7390D20009 for ; Tue, 7 Nov 2023 02:57:06 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf03.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699325826; 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; bh=KW9EAxCqYPaQVwMQMUZmZ+5U1OHABN2mDc4MP8/Is8Y=; b=2ghc7u6fIufZXATmOpYclw6P2iryOGzvnyQjq+9hwAbABumit5WB1r0Kpu4SUxiXAjRmxK 3LqI/3D5u/k9v6WBeb742J98VapZg18FR7+ivJi6A9fOsRq6yrEQUM5CkPBQzMmppa54sZ 40Wn9wlRYlddvZA+e2vE4tv0e0PoHVo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none); spf=softfail (imf03.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699325826; a=rsa-sha256; cv=none; b=2WLT0MDYVFlmWWU8BEKOKoWoWN+KoiS0OqlvfWxaOkr+3O4oZ9eLDlwQxTcgT4Ofcut8ew xZfxGsj6LaOsh03ExkOQprqt1hoBeiC/WSeu0/t682h/NmEUBht1FQSsj6sp2VdYkNR9vX lDSietvyFdQJkQvkGTMpEe+sTC6R+RE= Received: by gentwo.org (Postfix, from userid 1003) id 3828548F4B; Mon, 6 Nov 2023 18:57:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 346D448F40; Mon, 6 Nov 2023 18:57:05 -0800 (PST) Date: Mon, 6 Nov 2023 18:57:05 -0800 (PST) From: Christoph Lameter To: Roman Gushchin cc: Matthew Wilcox , linux-mm@kvack.org, cgroups@vger.kernel.org Subject: cgroups: warning for metadata allocation with GFP_NOFAIL (was Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL) In-Reply-To: Message-ID: <8f6d3d89-3632-01a8-80b8-6a788a4ba7a8@linux.com> References: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 7390D20009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: w3rc5x3ras5k7ex6kz88soraptmsuwgz X-HE-Tag: 1699325826-337835 X-HE-Meta: U2FsdGVkX1+MXRDEBFtDLJ+im/jrB0ldIhMT/uF2Ma3alP5SXS3aQn5lxqgkJO+3Y+v0PZhTqlPa968HlnqSTakjl6jgVBDxoVKwxPph7/zHIGHQTg++f4hE65TyyGNQHIH10SBEH2NULihkiobSdb9Li7Xeq6fjC6XjB3AN6rk6powe/pY6qB1mXFZG1ieHJ+xhXvLblPjxA+fou3U3jpF0Uy95jv+1KZ/cDO9Emtb0f+wR1W+hhnuETM/XySQn9ONrlhi+LiCkTnTJdTUcTX3A64/MJgcO+1LxSDGM1tPr9s1Tx0/MWv+jQL+u9R2TKvoOthed5BCNmAcmqiB3vybxarodhcDNASfNjZ+ily0R3c6xrBOm59GNHA3W7nxcqF+uIvNSTRQWbJGfPllIzRGFDkxYHqB9vGrYjLLC21aQ6O3lzoZ3JeVeaW0LuQ4Drwqy+t/RhMZQ+ltbhujIZygSgg7rshbEVEP8VZLQQ/3BRFP57/wS2/7sSE/CnaW3Hm6P+wk01v8OA8kuGbf7j3y5Rr4RjWHRrgmdfJUT2gCKVfsjyIW6wo0Dgge3/1rl1HIfTyH9A2JRe/GHfrWvVWm/+f09Z2hwya5BTmVsY/fLCBqMDda0r1j7Y+fgeT64DiPqYl+9mFCDfH1s8EdhI6ZfyDO158YNLsfSgqYRlKwDZHwfI5S52Is5oeg40nATgd8CiErW0IuiXKlnIfUYZtOox0w+A2uSZiYARN2IRdP8JYq9ICtHeliMPg+rAzInYrW8aahJl25xJYt9zoQOHJvG+X0ILONAu/VWciTMwyXLPYFQMsT8BBL2qvzLsOEApxUaM4S1S27OFwafpzDii+IN0TngzD8Cv6RliuC5xhVGEbtFt4Wm4gjUFQ334csRJaOvZGpBQTAf7EYAu/tUfnSpTsbAK7LmFwVq3BHKkpJ3NEFXyx83cagYSZEUzMmneFvK1RMKGJX0vNALqQn lUA7/gSM WlR5MTYYnQyjdu9pGOS/O1vY+rHxOCROdX/AX5j/4ZPaMw3JX8ql3ARtc3G8r52oFQzTJvnOWbe3BnIlyYy4etSPg5I8ZHJmxPYgQO4c/B2l79Zvz+krrnOKCnTp+sfWi1XIhEup7+2uXTXcQcYc4lZsvSbsCax4F2i7Y8tI97NP8psibKOSKQrz6Xw== 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: 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)); On Wed, 1 Nov 2023, Matthew Wilcox wrote: > 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. >