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 609D8C4167D for ; Tue, 7 Nov 2023 18:19:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD0EC900003; Tue, 7 Nov 2023 13:19:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C81018D0001; Tue, 7 Nov 2023 13:19:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4965900003; Tue, 7 Nov 2023 13:19:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A872F8D0001 for ; Tue, 7 Nov 2023 13:19:10 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6BE9C80ADD for ; Tue, 7 Nov 2023 18:19:10 +0000 (UTC) X-FDA: 81431970060.06.95D546C Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf12.hostedemail.com (Postfix) with ESMTP id 84DC84001C for ; Tue, 7 Nov 2023 18:19:08 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JT0kthPk; spf=pass (imf12.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699381148; a=rsa-sha256; cv=none; b=1ieTspiCNn0v26I+gl7lQXjE8BJTv08zjtMqWvDK19xFDsCO4NAzf6pW9OzfkxGMIHPvG8 Xk8m1pjtdlfUia/KsgqrYQnNVCMhP+3XizybUxlAwIWPkoHoNE1MUMrAPvitlWA7qcHJm2 QAhUkdfXph+cd8Jb+kORNs1DEnH/BOk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JT0kthPk; spf=pass (imf12.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699381148; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=u4/j39UfKajKlpqWroZ/BEjZObIZrH45V7V6jm2YWw4=; b=Xs5/JiMUvswNdTqA35WrDd1HdJ8LvRhaiLkY3PBx3cEo95Rjm+xvBKjcVNiWCVXOnhdOBi iEW9vlDPyx0EpY3g/gT2+J9KdeA80UkmeK/Ug30zR8mxZTkdZ5XiEsuvJZtnl8ibnMD4fq zPiB5EQy/bomQBVN8z6qq4/yL52pHKQ= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1cc209561c3so12185ad.0 for ; Tue, 07 Nov 2023 10:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699381147; x=1699985947; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=u4/j39UfKajKlpqWroZ/BEjZObIZrH45V7V6jm2YWw4=; b=JT0kthPkQnC7spNPf3kzpxHkxLzfeA2Y/LRqXpDAy+LcQHubD83wMHgGVEUB7A2TXs 54Z4elUyEyiVgd5nfnd+ErGKZyh5xZ2SIYjrNMMxlluJHV8O9/AhDda1uWqz0tFK/2pN 5myf2R844vBVydrgnFttOjTsryDaK2g9VaLW7aEIItiXvScECHQP24pXHpv/YiUeDvBm FbyqNv4UuP2a8rGcvBro3kcuC/+9rPbcqgtxsPvGbZQ7gAHBoFCCB/SDOJwASIyWrzMR llekgjvv1Yt5Sp8MbL0QCVQrf6/6zcZ8+1V8fj+axkL9gM4M7T5F7eg+4SGbQHf6phBx dHMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699381147; x=1699985947; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u4/j39UfKajKlpqWroZ/BEjZObIZrH45V7V6jm2YWw4=; b=C/BTeJLX65BmQJTrNeb98jbB3tMmjnc78WexTMYAGcqE8SAhocpnnAjNB4RwC4XM0Z OCsb9MqI33BjQRcqOJirzCGuf2ARrUTiHPA8DnJZwmLZFCLxZeOMQwnLzSsVZ/Eurgr7 mWTNEuFAHilhwzj7RYKgho5mHbzdkgih6Fv+PYYrqA/GbI7NB88XTqgVtTdYqcN6UByl YZW5jiZcKr30tw2SGDJTfO60rV5jdhRieuLIzCVEiV4MWFykXKxgLviY/nda5wJZsBEO /0GIyiH4C7wDquCfxQ8YRcSz/xwGYVOySowXdxp2+Ni6mX4OmGH5gWyqMAEp27uWKrs1 ABDA== X-Gm-Message-State: AOJu0YxIy/kUdihqORevaXjlGnZoGzd7ya3mCiAVPC8OtRfE+ymMPBfJ nnliqVv6duyBgUyX3ajl8il386JL7LUBscg7CbrqWg== X-Google-Smtp-Source: AGHT+IEIOlmRzYsnwMGgspg0jnKqplPYDta4kTiHJrISmeoAjbnmxJSUTBCI9/EYOKsDX9OTUesJbZ0LJ6UOJ7Zv0JI= X-Received: by 2002:a17:902:8bcb:b0:1b8:b564:b528 with SMTP id r11-20020a1709028bcb00b001b8b564b528mr242144plo.7.1699381146878; Tue, 07 Nov 2023 10:19:06 -0800 (PST) MIME-Version: 1.0 References: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org> <8f6d3d89-3632-01a8-80b8-6a788a4ba7a8@linux.com> In-Reply-To: From: Shakeel Butt Date: Tue, 7 Nov 2023 10:18:55 -0800 Message-ID: Subject: Re: cgroups: warning for metadata allocation with GFP_NOFAIL (was Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL) To: Roman Gushchin , Andrew Morton Cc: Christoph Lameter , Matthew Wilcox , linux-mm@kvack.org, cgroups@vger.kernel.org, Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 84DC84001C X-Stat-Signature: 4ssbk1j3xxerew8z5cjf9tgdf1h835dz X-Rspam-User: X-HE-Tag: 1699381148-145773 X-HE-Meta: U2FsdGVkX1+a4PajNTXvk1WdezIwC2I4d74uWC5ZUUkTkh/BGLWOkT+5mMj3ddnqx5L7+nJlLPLs35FLdrNP2XH9RynmAIcaQvaiUZszsYzS2SJqGoN9ABwJePCDTyrR1Opl9JLz7ix2kyGq4u65CscfRH2glhBbAjJ3bqwXOYahabncs9Ui+fTzMKgi0QmDxuw0wPzNMk2iHgw04AQmtg2LmYCzxhPB4JjC9fUbXwxzH2Hw/vgwck6W56zXrBIdr+lMHh+LuaXMfonVFcMtiOKxOMP+bTxoXT+MdtEbZZR9PvCf0+hB/J030cczUnDmXekGyClmhgPFAhqJER7RrgTQzRa8uwFjDSYVKK4IkaDldf8ApwBHJuDH3kFyRMRFz7cQ9pz0pu1d95KgROYUv1dAKvcAhF5AHD2tQaWEfW3xiTtwSclxYA7JGN5Q11LNu1metNtY9LqijSwwdwAddQ1qjuHFY/hAXNI8zlRk2yG9OjzodCGqHsJg9L6D4EQmJOpnAkj7cEcmCLPjOtcLhuTpLGAIolqdCf5oQ43IaOGigEreC0fWwttu0zUC7yvjLC/PiGCuq4n6FVm4Bp/0D+jX/FJthCu+Q+Wl5cthA9zkynXN8YvH9xGFpNYwzQWllcCFj0w3UGI9/WpdRXL7hCiITwkyClMNBLZp4idrZcFg7xZNf5xnBkol+mnn9wnJCL3GYTAHNGscIgw2XO/Sd0VpAK2vdZq0R4YypVmA+5P4Nd4olUgCk2YqlRtNDASOaxhPSqj5VjYBj+cBBTx+Oex9514Izc8uNgP/amafgmld1DjA8n26ByHJOR+BaA7lq/U9heaQv36pdFDdCbbVbpyZhXhydjiOK3xZ9oFGGk5d5f24g1H4ebU9bwUZfd4P0/1tiTQfZ4ueCllNDGqqDjUIsJr1Ixq8tvfVIYn9tQmr0jQvtYcmBKysCHprUeBip9Q2FmstmtiFdEh8MII oO1ulbcy QQU5XZmGqlIYy+K69069I1BE6MG+mHf+nZciY0bocjLp5yF15IICJCP1HW2oROyPznK5OxkC+6zPdlIedhg5t/lf4tzbNN9SN1x1FNMujcQdQWkXfJlj2KUEmM4PxLnhhsYQLgHlj0PHSVBwVykokpYe8KX/4xAJp3nVBaaQkF5ciXYEwQ6jYpEx0CDUM5+vG0ZHL9J0foQNjAVmxYbWzSpUzVhqUoFm17LenPwwSb4PG6YqwCe322dPTQ18060Pkl0dPSyfXTjmIJl2TsjRdxQp7X8SwNrfp/IWHsjqj0miJ/yQKJb9lPVQdAYiuLht3jKlZSzixMQ3SbL0GXf3NqEJhJeHZX3eiPxqOFMxwHyKeuom42QJAbHua1l7+haAvfGgvoM5RLWa7/5+UJ9P+BvFn8ETW14TUrK9M 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: +Andrew On Tue, Nov 7, 2023 at 10:05=E2=80=AFAM Roman Gushchin wrote: > > On Mon, Nov 06, 2023 at 06:57:05PM -0800, Christoph Lameter wrote: > > Right.. Well lets add the cgoup folks to this. > > Hello! > > I think it's the best thing we can do now. Thoughts? > > From 5ed3e88f4f052b6ce8dbec0545dfc80eb7534a1a Mon Sep 17 00:00:00 2001 > From: Roman Gushchin > Date: Tue, 7 Nov 2023 09:18:02 -0800 > Subject: [PATCH] mm: kmem: drop __GFP_NOFAIL when allocating objcg vector= s > > Objcg vectors attached to slab pages to store slab object ownership > information are allocated using gfp flags for the original slab > allocation. Depending on slab page order and the size of slab objects, > objcg vector can take several pages. > > If the original allocation was done with the __GFP_NOFAIL flag, it > triggered a warning in the page allocation code. Indeed, order > 1 > pages should not been allocated with the __GFP_NOFAIL flag. > > Fix this by simple dropping the __GFP_NOFAIL flag when allocating *simply > the objcg vector. It effectively allows to skip the accounting of a > single slab object under a heavy memory pressure. > > An alternative would be to implement the mechanism to fallback to > order-0 allocations for accounting metadata, which is also not perfect > because it will increase performance penalty and memory footprint > of the kernel memory accounting under memory pressure. > > Reported-by: Christoph Lameter > Signed-off-by: Roman Gushchin > Cc: Matthew Wilcox I think we should CC stable too. Acked-by: Shakeel Butt > --- > mm/memcontrol.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 774bd6e21e27..1c1061df9cd1 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2936,7 +2936,8 @@ void mem_cgroup_commit_charge(struct folio *folio, = struct mem_cgroup *memcg) > * Moreover, it should not come from DMA buffer and is not readily > * reclaimable. So those GFP bits should be masked off. > */ > -#define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | __GFP_AC= COUNT) > +#define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | \ > + __GFP_ACCOUNT | __GFP_NOFAIL) > > /* > * mod_objcg_mlstate() may be called with irq enabled, so > -- > 2.42.0 >