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 6D8FFC61DA4 for ; Tue, 7 Feb 2023 00:53:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C14E66B0071; Mon, 6 Feb 2023 19:53:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC52B6B0073; Mon, 6 Feb 2023 19:53:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A666A6B0074; Mon, 6 Feb 2023 19:53:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 96DC26B0071 for ; Mon, 6 Feb 2023 19:53:38 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6CC10A6BD0 for ; Tue, 7 Feb 2023 00:53:38 +0000 (UTC) X-FDA: 80438672916.21.94F4338 Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf16.hostedemail.com (Postfix) with ESMTP id A7A6618000B for ; Tue, 7 Feb 2023 00:53:36 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=vt-edu.20210112.gappssmtp.com header.s=20210112 header.b=Vdz0UCB9; spf=pass (imf16.hostedemail.com: domain of horenc@vt.edu designates 209.85.219.174 as permitted sender) smtp.mailfrom=horenc@vt.edu; dmarc=pass (policy=none) header.from=vt.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675731216; 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=51cn+25RJhtbSsnTQ7+kMH70MfRmDwmxDwX5ZXNBKug=; b=VdM3MDWnjtjpCImshsX4VOveC/nqZnN3O08Pa9HsclCU5hYt0qOqCVs5tbn3Xhk0gUKfol jwAWZalBFyM2k/VfMe8nQdYsvtJbNOPaIiD2XbLQbDNQd68cXMtKC7fTQTTdEXJO/ipqIM exmX/I9JMTCDCz78aMScMosAkEFBCrE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=vt-edu.20210112.gappssmtp.com header.s=20210112 header.b=Vdz0UCB9; spf=pass (imf16.hostedemail.com: domain of horenc@vt.edu designates 209.85.219.174 as permitted sender) smtp.mailfrom=horenc@vt.edu; dmarc=pass (policy=none) header.from=vt.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675731216; a=rsa-sha256; cv=none; b=UmwHKxJSueAxMNhQ8srWq6lMKyC0mbd9HJ4MoKLC/+m9PcFTHJwAHX4OAb0ivMVhHbX20J bV8+VfdRalkD2WQ7Qtay0xmG+/EfLrLkkFOV9/SE+b179kOAhMiPHdPGvtD995p+HCngoq AeIBDCBk1dRe7Xzr0cgl8grrT/SNggA= Received: by mail-yb1-f174.google.com with SMTP id x4so16666935ybp.1 for ; Mon, 06 Feb 2023 16:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20210112.gappssmtp.com; s=20210112; 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=51cn+25RJhtbSsnTQ7+kMH70MfRmDwmxDwX5ZXNBKug=; b=Vdz0UCB9jLeeKMfDH5sCBDeTms+EXqZOdTDB/+4qI0EoRL9L2P+NJFmpv3DcFKIBtL xndcINvPp4bint7iWB7y7trinEBIPvAzf1MbYunptnj+wUhFFblgY8zYYRp3J45aK0G/ DBinD+NhffPUdIO6MmbnLqpun8nKAqbP+u46jFPhTN6I8MniebNY+3TKyfQ5aodr13j3 nbu9gjc9FQ5V5TI1l30yHKTksf+2cgDt5Csyz92lpbMLTegodusBrlEhFGTbE8Czqye3 COm8mXYCgBfSKeTm65Hh3gvBUjkhw8WM1bYuB1mZhOvvqae6+MmDxCTsgsK49gGBugvU Lklw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=51cn+25RJhtbSsnTQ7+kMH70MfRmDwmxDwX5ZXNBKug=; b=rRRKXyBXiLPuRjK2QJMIMVO5J2etzpNvuijhW6gvxkkUDiQe+yHE45wakMgf3jxo2z PA3ueIx20jLeLem+GhVtDI0flb3gfYVw6F8uKtTxc2Z4Nz/08rDgXwgWyYCrEt/jbzGC ldSR62KXKxQTJHmSlX+x7SoBlTKugFUAlPjyN9YSZv5lnlCctZpgWgKiX9hZfXmeRWOi oKOPyYPWUsJu2iAotaNKFeIqeKsTXtu6q3MKaUM6ZSjJiI7i/n1iH3GV3kNQQowovs8M uCqUb2jWKma+mBRZDa14N7YGi51FLpEYh8fv+KyhfNRw3JRFwzK4OE/HNQfBE66g3zci Rxew== X-Gm-Message-State: AO0yUKXouKwgH0XATVjUiUBakMT2XgGgwtHbXNdlqUpCB4zEnSH7Ewkd ArbZdKx5sosiot+9YiPJwUY1G3EAPrqgdSP/BObciQ== X-Google-Smtp-Source: AK7set8ru7SLrkRouqjlWbYwRsalHwklMjTyeJcSICJDwy++QjDoIUzqmILAd0YYcSwq5XREW/b7i8TRBDiyUAzeRZA= X-Received: by 2002:a25:3285:0:b0:85b:e1a0:e95a with SMTP id y127-20020a253285000000b0085be1a0e95amr141956yby.593.1675731215655; Mon, 06 Feb 2023 16:53:35 -0800 (PST) MIME-Version: 1.0 References: <20230202014158.19616-1-laoar.shao@gmail.com> <63ddbfd9ae610_6bb1520861@john.notmuch> In-Reply-To: From: Ho-Ren Chuang Date: Mon, 6 Feb 2023 16:53:24 -0800 Message-ID: Subject: Re: [PATCH bpf-next 0/7] bpf, mm: bpf memory usage To: Yafang Shao Cc: John Fastabend , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, tj@kernel.org, dennis@kernel.org, cl@linux.com, akpm@linux-foundation.org, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, vbabka@suse.cz, urezki@gmail.com, linux-mm@kvack.org, bpf@vger.kernel.org, hao.xiang@bytedance.com, yifeima@bytedance.com, Xiaoning Ding , horenchuang@bytedance.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A7A6618000B X-Stat-Signature: reemsnbz5ktfihsc9fuy4njqpbyyzwrc X-Rspam-User: X-HE-Tag: 1675731216-222931 X-HE-Meta: U2FsdGVkX1+jd6DK2KoNX4wQ9V/OKMY4zK0irQY9wurkAL8oBfGGawmnjkmb9keMAcTUZvk/PPtJGx+swk0SpskFnsk689zc3R8wIYLIIU1bX54QoZFS7Y5ufzjk303IhblgxQaO79t1fw7vA3k/CSxTzAc/3nQ57H7GuHmtLNpA8a2xuPiBHbW11Ovp7dgIBOBUsG9W6eF8KLaq1+Qk8TSQdkyUmzupKYAKuhOoR2y1nJiDzFtIO+39spwXVj60T11Gv25RSr+B4pk+eY72pHWol0pufoTxWVLUr7NV3SAFH4q6L70s+JQoyVLIx5PepWaPRc1DFa29ljgFOIANnwE1x9tjgpgUhNO+dmiUMS9gTA5brTRW/bedziEkWF1CaUT8Aw4XsBuR7vjUDftjyrBx4eqVX5/lq3NOKAIjxVriDrFxYJn7nHFd7xontxUzkJI7PSmimdSp0K+ytWSwC5CXJ4X28/9eM4mtQu6kdqovRIwH0BEKADWEHcWOxBaqWh5d5pM+fmlJ6bA2HrbS7/u419xnFhc6FELhDA8TSNhtDlLb+79hN2zob/CYZ5mx3tBdJMFR8aYOaPXhoHFgwA/uecKkLt5A1oQiYYvdzFf0DmAEzJzCgFi8UB8/lm3pmeBDlUAWeqthDrEiexhWsWLR+xDad5FhYv0w9u61vaKTxgZbbw62WrqiK6XgAEuwYBvSORZa2Q3QCiQ+z6gw+4U37aieF0uiJIzIQ9jdrrIN36XYUOWYtMF3ckkDxgpm+euLpHaFjRlE3f0y0ld8/rUPe167/3udMw0YXAPtdumGF9V0R5hl0GRZYFMewajbSUL5aVpm7tiIs4h0QCEMOik/XtU7XAfNHGtWE+kNSpsCUEeBZcZnkjVTKMyQcibe3RrbA8lKhyWrXwBi6kTvLVPKU7LpbdkvdK/hmc3K63M2iFcMWlnvF54AEdOUILco5ap5KV1Iz+voapjeO6S UigElprT XwyRuwVznSHuXgyqgTEDBCaYQtqdC38V1v9Jg6Yt+jwaMY+X3poYx4IBjH+TY8dB4OUHSEDhK7UCaZJzQbczAWybYFnteyFCKZ9ptg5Om/0UuNdDfcQjMHRopHHD3opIW7BwYRMe8TgP2KaXKcc0CaW5A7VOr7MAEgOJ4ssxCRBBKMo8JVjZOmKAZmBaKzgv+ePrqEc09XbGtYo7TFz6j0uqLrJlG970UVopdniUNILlcZPzvNqvjqjIvIrP48tJifNmC75f1OOIXngApP7duMQfa8mNzzRrRwTdMAI6HLb6d5RrRZ1Y0pF9UMyfOubO/ZpW0q4mKkhzZ998UlEHzuuC7LfxtfSFmgwTjVQn13N/J3gmhOPaJFMKh8KtmLVIX/AAK5qYsTC6m2HfjjcMg3yewuf5bRkcZ+mo+5mm/grb0oSplJ3fC6Rq+lTo+qzqCP5Y3xAWrkVzEJ2/sCB8TGubO/A== 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: Hi Yafang and everyone, We've proposed very similar features at https://lore.kernel.org/bpf/CAAYibXgiCOOEY9NvLXbY4ve7pH8xWrZjnczrj6SHy3x_Tt= OU1g@mail.gmail.com/#t We are very excited seeing we are not the only ones eager to have this feature upstream to monitor eBPF map's actual usage. This shows the need for having such an ability in eBPF. Regarding the use cases please also check https://lore.kernel.org/all/CAADnVQLBt0snxv4bKwg1WKQ9wDFbaDCtZ03v1-LjOTYtsK= PckQ@mail.gmail.com/#t . We are developing an app to monitor memory footprints used by eBPF programs/maps similar to Linux `top` command. Thank you, On Sat, Feb 4, 2023 at 8:03 PM Yafang Shao wrote: > > On Sat, Feb 4, 2023 at 10:15 AM John Fastabend = wrote: > > > > Yafang Shao wrote: > > > Currently we can't get bpf memory usage reliably. bpftool now shows t= he > > > bpf memory footprint, which is difference with bpf memory usage. The > > > difference can be quite great between the footprint showed in bpftool > > > and the memory actually allocated by bpf in some cases, for example, > > > > > > - non-preallocated bpf map > > > The non-preallocated bpf map memory usage is dynamically changed. T= he > > > allocated elements count can be from 0 to the max entries. But the > > > memory footprint in bpftool only shows a fixed number. > > > - bpf metadata consumes more memory than bpf element > > > In some corner cases, the bpf metadata can consumes a lot more memo= ry > > > than bpf element consumes. For example, it can happen when the elem= ent > > > size is quite small. > > > > Just following up slightly on previous comment. > > > > The metadata should be fixed and knowable correct? > > The metadata of BPF itself is fixed, but the medata of MM allocation > depends on the kernel configuretion. > > > What I'm getting at > > is if this can be calculated directly instead of through a BPF helper > > and walking the entire map. > > > > As I explained in another thread, it doesn't walk the entire map. > > > > > > > We need a way to get the bpf memory usage especially there will be mo= re > > > and more bpf programs running on the production environment and thus = the > > > bpf memory usage is not trivial. > > > > In our environments we track map usage so we always know how many entri= es > > are in a map. I don't think we use this to calculate memory footprint > > at the moment, but just for map usage. Seems though once you have this > > calculating memory footprint can be done out of band because element > > and overheads costs are fixed. > > > > > > > > This patchset introduces a new map ops ->map_mem_usage to get the mem= ory > > > usage. In this ops, the memory usage is got from the pointers which i= s > > > already allocated by a bpf map. To make the code simple, we igore som= e > > > small pointers as their size are quite small compared with the total > > > usage. > > > > > > In order to get the memory size from the pointers, some generic mm he= lpers > > > are introduced firstly, for example, percpu_size(), vsize() and kvsiz= e(). > > > > > > This patchset only implements the bpf memory usage for hashtab. I wil= l > > > extend it to other maps and bpf progs (bpf progs can dynamically allo= cate > > > memory via bpf_obj_new()) in the future. > > > > My preference would be to calculate this out of band. Walking a > > large map and doing it in a critical section to get the memory > > usage seems not optimal > > > > I don't quite understand what you mean by calculating it out of band. > This patchset introduces a BPF helper which is used in bpftool, so it > is already out of band, right ? > We should do it in bpftool, because the sys admin wants a generic way > to get the system-wide bpf memory usage. > > -- > Regards > Yafang --=20 Best regards, Ho-Ren (Jack) Chuang =E8=8E=8A=E8=B3=80=E4=BB=BB