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 8122EC433EF for ; Mon, 11 Jul 2022 19:19:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDC8A94001B; Mon, 11 Jul 2022 15:19:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8D4C940010; Mon, 11 Jul 2022 15:19:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B561F94001B; Mon, 11 Jul 2022 15:19:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A3463940010 for ; Mon, 11 Jul 2022 15:19:57 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7726C33F5D for ; Mon, 11 Jul 2022 19:19:57 +0000 (UTC) X-FDA: 79675784034.04.8F4F51D Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by imf06.hostedemail.com (Postfix) with ESMTP id F3EF4180025 for ; Mon, 11 Jul 2022 19:19:56 +0000 (UTC) Received: by mail-pf1-f171.google.com with SMTP id y9so5550073pff.12 for ; Mon, 11 Jul 2022 12:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rGhsbgrOdse9F6x0ACAaLskSqS3ovFUrX7+4Tn05BBc=; b=VbqQNIJ7oNm70/p7Vv2pDX3Lg1qXKcNUXJKYU85ZVBPtzdtkZTRmF5HM986wBWZ1Xr +1aZYSlXK9mJr++7ZM1Y6OsjPkpeGQ7CtcXpYMc/ZBIx2hJri8E++MduFPc5cM0dxhqu ZFJasQnixUKypE6z0mkUDz1n6c8Mg26VC/nwTA8PXvtlReBdbi2Sx6kS6ZucPBURq23w JZ44FpxsceTXzSYoRoLujG4eVcrRlfr0DpS4DmlwQ6TbEgi3g0LaReLXUCPvFUANvK4u j7BulOxJs3kfmlFQw0ZBOPyKFDxvdSBTm8N96VW7YGovw/zpkulTNbp0Ee+wZTbbJxwB 4Lpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rGhsbgrOdse9F6x0ACAaLskSqS3ovFUrX7+4Tn05BBc=; b=MYSUx7j9lzHm8zAUxSk5lBFrIDT3GcOs0IjcnEjLcqbVOgtFr101wiegQ3rwlYGUuL peWmJiFC1lKBlqiH/OxUcaYyjuPPLNKDY4+ZJQISb5rtsUjZgK648J1+uegTYUSoqi45 ItsfZuSwG9YurtS46ssnhNxWPVHpScnQXvxaLk66DzQm3rGB9Xl+5RlNRQ7dFaNPK7o5 9IHVKl2KoMEEWybpgMzVQsc3RNflOM74kX/2L06w2jcuB4ae4E8rNVUwktJ0kO/uyZqm yIQLWQnEyudfsRm5jnwsHH5Cx6cgS6gdPLT9EOxfgW8UGbhAW2CkD9zVROwelIigxMox 3IrQ== X-Gm-Message-State: AJIora8SRu31WS6yrdQPcz3ClD3DHZt7KlPNIIQr4CDnPyphNtf9zWOL 5ubN/rhYmtbbvcwMG6lCrK6O4YpLcr1Mxuz/hi4qVg== X-Google-Smtp-Source: AGRyM1tdlTXiheowl7wsp9L89MHsalGcSsELsiyAmbWmEoqldeuUja2QlD+rUze/satfSH0yxJx9oT7zRN1L2KmNylg= X-Received: by 2002:a63:4a59:0:b0:412:8872:83dc with SMTP id j25-20020a634a59000000b00412887283dcmr17374282pgl.357.1657567195957; Mon, 11 Jul 2022 12:19:55 -0700 (PDT) MIME-Version: 1.0 References: <20220709154457.57379-1-laoar.shao@gmail.com> <20220709154457.57379-2-laoar.shao@gmail.com> In-Reply-To: <20220709154457.57379-2-laoar.shao@gmail.com> From: Shakeel Butt Date: Mon, 11 Jul 2022 12:19:45 -0700 Message-ID: Subject: Re: [PATCH bpf-next v3 1/2] bpf: Make non-preallocated allocation low priority To: Yafang Shao Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , kpsingh@kernel.org, quentin@isovalent.com, Roman Gushchin , Hao Luo , bpf , Linux MM , NeilBrown Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VbqQNIJ7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657567197; 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=rGhsbgrOdse9F6x0ACAaLskSqS3ovFUrX7+4Tn05BBc=; b=SlAU33u5m+twz/3mxHDweXlr1uW7L+1teiRtK5wDHEkQZTXcVDI9/Fog1ywmlX6KoNPGA8 nSHHfjO9Wd3ObeO3g7QUw1l4xFQcVv0k1ZUUaOhOoyqxcRtGoVoULzp9OlBF7x0CvOCfw5 WktMhJ8uiNwWk5U0NeCl2zqD9BaTt9A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657567197; a=rsa-sha256; cv=none; b=HQ61xxuZ36q88mRYMZeC1bg9sz+a+SVI59vqmX5uqb9QZd+NST/HFqTpLZsWSC73VGuKn8 N+304uMH69SLm0aTx3GD4z0tmO290aEFO/koMaYLmAne/uiURQxdcgzQEfNrL5n3Z0nDe4 6Izx7hRD/6WCwXHjaXf3c8NKgRbxUjc= X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VbqQNIJ7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of shakeelb@google.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Stat-Signature: 9fwpyh8thsghojsrhzcgqz1kwyxyfg4b X-Rspamd-Queue-Id: F3EF4180025 X-Rspamd-Server: rspam04 X-HE-Tag: 1657567196-477865 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 Sat, Jul 9, 2022 at 8:45 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. There's a plan to completely remove __GFP_ATOMIC in the > mm side[1], so let's use GFP_NOWAIT instead. > > 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. > > 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 > > It also fixes a typo in the comment. > > [1]. https://lore.kernel.org/linux-mm/163712397076.13692.4727608274002939094@noble.neil.brown.name/ > > Cc: Roman Gushchin > Cc: Shakeel Butt > Cc: NeilBrown > Signed-off-by: Yafang Shao Reviewed-by: Shakeel Butt