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 6D06AC433EF for ; Wed, 6 Jul 2022 22:12:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 095646B0072; Wed, 6 Jul 2022 18:12:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0456E6B0073; Wed, 6 Jul 2022 18:11:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4EFF6B0074; Wed, 6 Jul 2022 18:11:59 -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 D5D516B0072 for ; Wed, 6 Jul 2022 18:11:59 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AA5EF33A56 for ; Wed, 6 Jul 2022 22:11:59 +0000 (UTC) X-FDA: 79658073558.10.4DB4440 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf20.hostedemail.com (Postfix) with ESMTP id 50E391C0012 for ; Wed, 6 Jul 2022 22:11:59 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id u15so4935652ejx.9 for ; Wed, 06 Jul 2022 15:11:59 -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=+2seMBdUCNd9lkwUpWfSizm/4BlRcABqRSozYyXF50E=; b=ZfwpTK03Wo4ML6HpI6A3X8CcNFeMmO4AEmA4QWmrwEHZ0VoyWyLjjbCRUNSlDn8vPl NVsI3KYRKbhBx0fPkrTQC4g7eZSh8QGubOH1H8cta/ogwn2NeggVrsnBu9sv+9Qi5Sms w3sS6L53aF1VXpUKHOOpcbv1+gd0zFp8+p5QCNIk3GOre1mX+BuTKAMbVo7DQeq8e+Bd ZD3u7Yf0YNeM3nGs57IH+bvK7GyHSzPgrWS+HHyBDvN/9R1tbKArX3ClV8TAMXiEbFsX cKcS5YQJ63zamuiuO8UelLro30FvQA94LT9L/qw1h6uf8CC9vZU/2dG4VwThTsy5d/e5 XzTQ== 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=+2seMBdUCNd9lkwUpWfSizm/4BlRcABqRSozYyXF50E=; b=keS9iB9foFVlpRC6/3VYctWs3fnx7VHFI4/QLyTcAyXD5g23Yqt9JfvLeR/34RPbj5 5tjvsU1a8kHik2NVpPVNCLYbqJFEjA+lHf8YjMXODLOJR26jdjWxR0+4nBbb81U1T3iG h1ch2BsazdJ+rpi+27vNTm6b/aoXl53GXm7BLb7TOtdXPQ+9BfbhSSvP1jlxjTMo1jt+ +JnjdcAH4ZCOibYO8NuKgExue9A58O3iBETJIbw+uZ5P1Ph49SSI86Ta05tgRdZUgY4q eth/NH2W4t/F8gvShFZjMv3qECHkIEhb9k58HUExW13aXIBA42Yemk6MRqpi4Ex8dnvh RdVw== X-Gm-Message-State: AJIora9PonCKEPY8xzAnPJt/cLSPgjtSrZa9yO5uR8HmF9reRzCaXc0t F93B+zLkTYXY5ZCZX0NlfqP3NQFHoC8QXNdHHhI= X-Google-Smtp-Source: AGRyM1uuHUKmzMHU/3+birBCRNj94wTTZv/olVbyjxU+t348hHCDIcHEzGXwXDCd0+FDcT1chOQNADVsyL/3lGicqIA= X-Received: by 2002:a17:906:6146:b0:722:f8c4:ec9b with SMTP id p6-20020a170906614600b00722f8c4ec9bmr43656408ejl.708.1657145517968; Wed, 06 Jul 2022 15:11:57 -0700 (PDT) MIME-Version: 1.0 References: <20220706155848.4939-1-laoar.shao@gmail.com> <20220706155848.4939-2-laoar.shao@gmail.com> In-Reply-To: From: Alexei Starovoitov Date: Wed, 6 Jul 2022 15:11:46 -0700 Message-ID: Subject: Re: [PATCH bpf-next v2 1/2] bpf: Make non-preallocated allocation low priority To: Roman Gushchin 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657145519; a=rsa-sha256; cv=none; b=Fuy93Lx2ON0WKd56x4iLlAMVYkdvi926rXDb9lDAIMrWkfjCn8LhM9SOWBlukvzEPeh8PJ bRJDRM7pzjCKnp5UoKb0gIrZ9nA5ndzw3utxxte69bb25w3MwkA5IfY56CCFOQw4eYW7ic 1PIXSRn1rAStS+t3Ylf21NBMMXm+s2I= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZfwpTK03; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657145519; 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=+2seMBdUCNd9lkwUpWfSizm/4BlRcABqRSozYyXF50E=; b=tDUX96Suft161KOBVa0+G+NX1DJaR7cKajFFVfXJa0g/O7nqI5gFqfRTjb1SwgS/txH4ZD NfzAjp8+kNh+XK83IExdnPDzdrikS/cvvRAhntjbaGIS78e6AU+MBMO8qkcWh3NPt4xICC e0EqCyXVszdFQNPoaXEZ7YmUDff3V/0= X-Rspamd-Server: rspam04 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZfwpTK03; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com X-Stat-Signature: yuasmbsojijqqnqjbr5fqwc585eptuou X-Rspamd-Queue-Id: 50E391C0012 X-HE-Tag: 1657145519-265805 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 12:09 PM Roman Gushchin wrote: > > 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. Yeah. It's a difficult trade-off to make without having the data to decide whether removing __GFP_HIGH can cause issues or not, but do you agree that __GFP_HIGH doesn't cooperate well with memcg ? If so it's a bug on memcg side, right? but we should probably apply this band-aid on bpf side to fix the bleeding. Later we can add a knob to allow __GFP_HIGH usage on demand from bpf prog.