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 3C4F1C433EF for ; Wed, 6 Jul 2022 16:47:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B66B26B0078; Wed, 6 Jul 2022 12:47:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B15D46B007B; Wed, 6 Jul 2022 12:47:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DDE46B007D; Wed, 6 Jul 2022 12:47:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8E8F06B0078 for ; Wed, 6 Jul 2022 12:47:46 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5C5E333692 for ; Wed, 6 Jul 2022 16:47:46 +0000 (UTC) X-FDA: 79657256532.25.2ED6ED3 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf03.hostedemail.com (Postfix) with ESMTP id 0F78720010 for ; Wed, 6 Jul 2022 16:47:45 +0000 (UTC) Received: by mail-ed1-f42.google.com with SMTP id e40so20026358eda.2 for ; Wed, 06 Jul 2022 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oxZ1uVRXPYMhnqF7XQQhd8OulBR+8nYW/g9JzEVE+2A=; b=k84o+gSYpbG00hZ0Mg7hBS89md6qUTbgQvj0lOchOx0QXCQ2VRSPyiVY722TcScGwT Rbre9J+hNmDz93rIeAfbyaXvcuUq/uOnxQbRwTxWMlQMAHnEbd+Uc30vzcXZ4YT1zDvu mPz5+WtSbyJQIOQR8pSErdztxpXWa6I1CBlIURs3PqouCI9BbR0Mn5uq/GFBVplTDse2 k0jSGeESbJVSfspWxCZWng/KL4bXagp9S537es5h81Z64LWa0Ac1nEn08BewMBbbjI7t bsE32uOWuYiPWaVa+0go11kPanGTtMXw/48B8v6xTCO+XppsM3mdxmYmYdzHRbx2mY+k tV9Q== 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=oxZ1uVRXPYMhnqF7XQQhd8OulBR+8nYW/g9JzEVE+2A=; b=rLWoeQzk7u0wuqPqUuG7DTdkN4xrhWAvGMOhSX5wAq23MbzNhXbAypdTwIjBz3piS5 Wnb/vq2kS57alguZWL4JavwyQBSX1JxT0FWELHvTH8AASxTEUGI8am161IpJhvAD2ugK AJAnZuIUM7sM7vE5SPddWj6vZ2fuxRo2xuGpkoL32p4C4UIgmWGFtzfhou8IYhQeQLS+ vYn1Gz4kltH7tKlx/81s4mU538g/NELbgEa+Ol1Z4j1Nh5ndIKlsIVVM9KrsM0AT6Iad aaEaoJlA+RE2mtIEUG0z+h3KFYSvaq2xQCo8bYL8Co7J9ZPxOmznzAG+33oSY3wdyAe8 YeNA== X-Gm-Message-State: AJIora8Dmz1NI5PRLNmHI2ju/VbWcGl/96Tlrpo5bueBOWZ7udeVaSc6 pUrTbbUbLTRTyPY7mn6Oy17kq9YmSJBupnK8lXc= X-Google-Smtp-Source: AGRyM1uifLnZXFC7DxjlD78F9165GHQ8KEcrLdeXZl+UM2dlqrrC6sbikjqBdb0xh37CNTXQHwD9i0bAsPPcTnn3hWQ= X-Received: by 2002:a05:6402:51ce:b0:436:7dfc:4840 with SMTP id r14-20020a05640251ce00b004367dfc4840mr56163241edd.338.1657126064703; Wed, 06 Jul 2022 09:47:44 -0700 (PDT) MIME-Version: 1.0 References: <20220706155848.4939-1-laoar.shao@gmail.com> <20220706155848.4939-2-laoar.shao@gmail.com> In-Reply-To: <20220706155848.4939-2-laoar.shao@gmail.com> From: Alexei Starovoitov Date: Wed, 6 Jul 2022 09:47:32 -0700 Message-ID: Subject: Re: [PATCH bpf-next v2 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 , KP Singh , Quentin Monnet , Roman Gushchin , Hao Luo , bpf , linux-mm Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657126066; a=rsa-sha256; cv=none; b=CYkqI7XDjMJqYHnqmtau0Bh7rCm8EkiMVdok4Ghdlrgk7gFs/PWNYoQqj7OuVKuh2t/RtH uQM5Cs7UOG2CzgGUT8dWav+yhne0EcgP3HpIcqnMtPYsiTNk6GZ/cmJdd39vQJ1DuWk8M2 c3TbWNgOTmYWMJZGpNmTpQJg4ma4yEY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=k84o+gSY; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657126066; 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=oxZ1uVRXPYMhnqF7XQQhd8OulBR+8nYW/g9JzEVE+2A=; b=gVsyrnbssB6ETdkN908LvhTk7auBI9BKnT9MF9CdiTyN5VYMzyrwAL/YrejrkFbbrz+cO1 WcjyzUvDNxNN8nk9gUYW75+Ieo3+onWNCxvoL/PaCi27+pBBnJ39nHtnSlJpjzGUbmvBzA ciK0xEqfsizL8OQIvf2+UZs65si5Rdg= Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=k84o+gSY; spf=pass (imf03.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: bbqtwoupbbpxby7i51aa6pt6pw4mwzws X-Rspamd-Queue-Id: 0F78720010 X-HE-Tag: 1657126065-650776 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 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 ?