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 94835C433EF for ; Wed, 6 Jul 2022 19:09:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 138686B0072; Wed, 6 Jul 2022 15:09:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 076FD6B0073; Wed, 6 Jul 2022 15:09:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA7676B0074; Wed, 6 Jul 2022 15:09:25 -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 D117B6B0072 for ; Wed, 6 Jul 2022 15:09:25 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A47E460C30 for ; Wed, 6 Jul 2022 19:09:25 +0000 (UTC) X-FDA: 79657613490.24.7E20846 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf14.hostedemail.com (Postfix) with ESMTP id 2BDFA100043 for ; Wed, 6 Jul 2022 19:09:25 +0000 (UTC) Date: Wed, 6 Jul 2022 12:09:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1657134562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZrV9gZ3M7hyQBQVRJSRAAQW/nrB76C3hSoG3FLTFRhE=; b=BFx4o+Zn4HPzQFdHpfNqlMh1lYd1NMy8h3VaezauIwjA8OuK0rPGJaq4JEqFw05wcrijHP v/aI2kTB43TrYwvMPbf05pv+FKDJ5Jce9v5+CyGtGYT83lo1gGAjHRJ1/py93hMVbaSayb PS7K9X5SMbX5MJPFIlU6c5rYOyfVmYI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Alexei Starovoitov Cc: Yafang Shao , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Quentin Monnet , Hao Luo , bpf , linux-mm Subject: Re: [PATCH bpf-next v2 1/2] bpf: Make non-preallocated allocation low priority Message-ID: References: <20220706155848.4939-1-laoar.shao@gmail.com> <20220706155848.4939-2-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657134565; a=rsa-sha256; cv=none; b=bVjrwM4ahhtp/JctQyunXxyrpCv9oDYNAUPQ8ZW3IDxQR+xEZGgHMl/b4fIMcQgogktIeH pjzS3vJvyDeuetT5C7n7O/yzLB3pZAOYi6DNGeLo7tc+Qia7B/9WLgIj1cRr/g51Ic2eAN ZGaQEXFAFg+7HXtQESvq8TeLwQrnXyc= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=BFx4o+Zn; spf=pass (imf14.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657134565; 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=ZrV9gZ3M7hyQBQVRJSRAAQW/nrB76C3hSoG3FLTFRhE=; b=L6CzXBZ1b9c83mQsu/ySZX7vBzuFfOoWQk0U7vB4slwIUuqzHWEoZ6IGeYxh6BR+cZmKFA 53VM9VIFy/M0wxCdEA7HWi4JwdS65CzYTS3FGh1Ox9JF68AlLOZd9+CuZgDI6bjqy9oaWS mC2Bxyie44YefLj66Uj4Xm29CdlBMIM= Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=BFx4o+Zn; spf=pass (imf14.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: xsrijm9nhcokfk3qh9seeinmojzkr6uz X-Rspamd-Queue-Id: 2BDFA100043 X-HE-Tag: 1657134565-519490 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: On Wed, Jul 06, 2022 at 09:47:32AM -0700, Alexei Starovoitov wrote: > On Wed, Jul 6, 2022 at 8:59 AM Yafang Shao wrote: > > > > GFP_ATOMIC doesn't cooperate well with memcg pressure so far, especially > > if we allocate too much GFP_ATOMIC memory. For example, when we set the > > memcg limit to limit a non-preallocated bpf memory, the GFP_ATOMIC can > > easily break the memcg limit by force charge. So it is very dangerous to > > use GFP_ATOMIC in non-preallocated case. One way to make it safe is to > > remove __GFP_HIGH from GFP_ATOMIC, IOW, use (__GFP_ATOMIC | > > __GFP_KSWAPD_RECLAIM) instead, then it will be limited if we allocate > > too much memory. > > > > We introduced BPF_F_NO_PREALLOC is because full map pre-allocation is > > too memory expensive for some cases. That means removing __GFP_HIGH > > doesn't break the rule of BPF_F_NO_PREALLOC, but has the same goal with > > it-avoiding issues caused by too much memory. So let's remove it. > > > > The force charge of GFP_ATOMIC was introduced in > > commit 869712fd3de5 ("mm: memcontrol: fix network errors from failing > > __GFP_ATOMIC charges") by checking __GFP_ATOMIC, then got improved in > > commit 1461e8c2b6af ("memcg: unify force charging conditions") by > > checking __GFP_HIGH (that is no problem because both __GFP_HIGH and > > __GFP_ATOMIC are set in GFP_AOMIC). So, if we want to fix it in memcg, > > we have to carefully verify all the callsites. Now that we can fix it in > > BPF, we'd better not modify the memcg code. > > > > This fix can also apply to other run-time allocations, for example, the > > allocation in lpm trie, local storage and devmap. So let fix it > > consistently over the bpf code > > > > __GFP_KSWAPD_RECLAIM doesn't cooperate well with memcg pressure neither > > currently. But the memcg code can be improved to make > > __GFP_KSWAPD_RECLAIM work well under memcg pressure if desired. > > Could you elaborate ? > > > It also fixes a typo in the comment. > > > > Signed-off-by: Yafang Shao > > Reviewed-by: Roman Gushchin > > Roman, do you agree with this change ? Yes, removing __GFP_HIGH makes sense to me. I can imagine we might want it for *some* bpf allocations, but applying it unconditionally looks wrong. Thanks!