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 2E595C636CD for ; Sun, 5 Feb 2023 04:03:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A335A6B0072; Sat, 4 Feb 2023 23:03:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E3506B0073; Sat, 4 Feb 2023 23:03:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AACC6B0074; Sat, 4 Feb 2023 23:03:44 -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 7804D6B0072 for ; Sat, 4 Feb 2023 23:03:44 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 480CB402E4 for ; Sun, 5 Feb 2023 04:03:44 +0000 (UTC) X-FDA: 80431894368.16.9B21759 Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf13.hostedemail.com (Postfix) with ESMTP id 8190B2000C for ; Sun, 5 Feb 2023 04:03:42 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Aa1mix3e; spf=pass (imf13.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675569822; a=rsa-sha256; cv=none; b=XUIeavlQAKR8Fw7kZ8gQnpBbpUsUDPKvrIxhWRSn8WaCoVmNlhp97Dy4e5ainJeRyIVTJB vQZET3FPnWtBzSoOKPWthlYJKhib37zN2M0rXg/qgQ6FloJ8K+0ZwskeT3kBJUJqmLkOuf McGB3ASjA7AJ6DLNd/PP4CMHiY/3yVk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Aa1mix3e; spf=pass (imf13.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=laoar.shao@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=1675569822; 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=AaRPKrJenXRlZJRlBBTvbxO+nfonIN+I19ij1t4XP64=; b=KgJSvbEtcg7kKbxMtz0Il3y2ecgPQLZPqgquTG4E/5aSdAhfb87R9XWVBXOd4JnBEw3P6C UbAdAdMh2ocLVC0PonESfKn/CTWeZSIfCczw3naRmK7wVge5pvAyM/BH0XZi2xV8vJI6WB DY0sHtN0L3F1UBqLLOco+UcPIx5jcxA= Received: by mail-qv1-f50.google.com with SMTP id k28so5287717qve.5 for ; Sat, 04 Feb 2023 20:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AaRPKrJenXRlZJRlBBTvbxO+nfonIN+I19ij1t4XP64=; b=Aa1mix3e8gLG5LLSupYiWkuEHwoutDVPEZSZ7NJdZJPxtIf+K1HDgEKH2VNSqChHf+ VrJ45A874dIqoRl64MuWs58lolMC78y20HtYFJ+FBJRo1FZgH2ITWVFuI8I0JOASynsp 0uYKaAR1cwxpQDc6uXzQyypybseh3z5jLWpv/1UVO97bOiqPi4XGa8bAyQHqcxED6WP3 qadOIoznP44B1kmPL1vGuS3k4WWq9piCRtkBZRdy4FtrbNNMS1irHz39SayE7rGbg1va 9ewW/i094JsrUdettae1Vr8oO5KAc19awwbXWlfEG6D8X1ljdJ0pXrFLul0w7bWenatx DDtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=AaRPKrJenXRlZJRlBBTvbxO+nfonIN+I19ij1t4XP64=; b=76Nq8ZlKm9fQ2gw4vlfcOdeiMX+DJVfqQSnP1HW+PJKro1+vXyKXlCO1Ss5+ry31b0 er9+12RccYCi/fHDRkkN5gXs9Ykl+eowbu6qYlejR/3WIv5JT2NIHdR4vA0zjXsj78lJ 9s/pgqyGwrzsFADijagus1LOAQl7y5VlwGmFu0L7QcOEKn4FPnOzodEgeGgD13HwMLRU 9Ni248aZm94vmBy/6qIJM4ARoeSP09h0mCrx9+5d7M/zbVJnFnUZSw14IaTbhzh0wupi 1D8lP2oOK4HiHjDfolDMjiLeMbX23MYWXYTINfP1Z5yX6DN96Pc6hqwysi9k0mYYYZdA 0pBA== X-Gm-Message-State: AO0yUKUQp1H6F+hEq+Tgb30wF5wxwkMtECIlQfC5Z5dnDyYK5dxGcKb1 Bxro5HJ2GtCyw2H3yB99+4dfau3n715KrJwCksE= X-Google-Smtp-Source: AK7set8W7nYgfrENJ4TTYMIbustDq1gYm/g5s7cOtFvu5XJzRHm0MGd9YbMkaAzPRxr56Xb31usjP160ASIBpmqBhbE= X-Received: by 2002:a0c:fa52:0:b0:537:762f:48c3 with SMTP id k18-20020a0cfa52000000b00537762f48c3mr921710qvo.74.1675569821613; Sat, 04 Feb 2023 20:03:41 -0800 (PST) MIME-Version: 1.0 References: <20230202014158.19616-1-laoar.shao@gmail.com> <63ddbfd9ae610_6bb1520861@john.notmuch> In-Reply-To: <63ddbfd9ae610_6bb1520861@john.notmuch> From: Yafang Shao Date: Sun, 5 Feb 2023 12:03:05 +0800 Message-ID: Subject: Re: [PATCH bpf-next 0/7] bpf, mm: bpf memory usage To: John Fastabend Cc: 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 8190B2000C X-Rspamd-Server: rspam01 X-Stat-Signature: y8469y47catihw1fyujktamjxaochmzu X-HE-Tag: 1675569822-166637 X-HE-Meta: U2FsdGVkX18IpASpdaL0TOGpEGu4NjPpGIblJVErv6PuPrkgQ4rClGV9ONEfuay0+LY+BbZE4jABlIlbBkt2ji/hh6GihviGggrNWIOi1JIYzkT1k7uFXxx/XytwPFYhdjDhOcjkIf45omITDfHh7px3Qa5jXgmCQ9MU0KmpLdWjeswhNk9gl2O9oUVtC8jlu9pbxv6d8qe4zCfH9CnAF0lh96JD23iIo1K8dXLd+HZI7iQ006UFAv+wtvda/n/oSqhazfjA4ayqgp+eDgRuJW8K1TBMvT9lpGzVNjq78TFwSyp5LV5wMt3cMRam+gjYX1d+ks4Rzn5p4IDdZ7wJqWJRjDkYazQnGBBxH56rG+ONraLosGFDLdGnhF32Il+AHPUeanVXmYtmNEYrqwoPmYiON+P6fbFmb/G+oU7zjWbWD3kPuXpBiEm3x2/tzExlDozywqCAiycMqHNB2FFOexSqZUeP3P3riXJwSKwr8akFqjpE4oNMZXODhhRByVzYye3Z3/q3gJQe1xKRKzwJP7z85JClo0JxgoZXS242X9N3xX6ZLaJWH1qDrX8Zswg6gEk3YY3spsfGvEVeb8Q/n+bnakm9pUkZQTdPbR1KRT8z8jpsUqJbJ+Lp1kNZxPMN+xDzHwvAqn8kEiuWFvZE2PToqj09ZZGaeiFl4unHttuWnhTBaWW5/t1+WoM9t9s/KsYIO/zraq0K9LP3MdHK+mhVwF2EJx5WzMrTJKpqFB/Z8GKRabUoHiNtPTEWXXLm6xXL7puJbohDZVYCqX6fyrGC7YcURnAUqznvf9cNpR/OvE9TX0hbXFgSKAqRAu15crmT27g83QqqG3QiEk+qx5Ied/zMoSAYirAXekQHxO1Or6PczS1J7E+yDhKCf7yYM0yc5pqUALBlhNK4t1bghqI18XpfefsmmM6dYAehmo9R6BJsV+Kwa258z1UiJapEEyLH1YRQ1WG9NiV4u+d k5aVXF5G qaOXvBP20Uaq4o6V3ISTtr3hcawg8X9PpobV9lMzymzajC1RpU94wOo4Mc6NwpLwpvp4d8Q068C99p/niq3yL068mcBggD+r5FsLw0u3iKu+0r9iMLN5TWYzbp92bvu35t+S+nRzJD6j5EyxxWxrQuGIiQ3SoN7NdCO/ae6cwGlgNlQfrV9099dT6SfmV0cnyw+EbVTgtmTNrHpGRzMCY8otlUZxAI3tcEETSn6Zk/yF+yiB5Onb4PjtdPzyBNLSML55SxoaYZfWtquZgyifOmc+TVp7dOJ3tR1Ax/VrLKGjhihOS/9Jo28Y1Ickm0FXSqN+u1EFtp9T+2eieM2RuCXhOGMxsBQUv1++gJtMDsl2XP0YV/GNZDBUnzzAw3XLw1drVOOcpVdRhacAuqKpsd30xf6WCT6yQKafadjci8RphkJDGzfOuCsPw3Mtj1TDKN7o9wKBYAB8YKcop8VuJk+J6eqVjuiyYRzgTexzcE9bElZmShsA/avLdVGVSMQfJvluxZSpMZ0SDb1/Xc4XlZ0pP1Q== 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, 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 the > > 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. The > > 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 memory > > than bpf element consumes. For example, it can happen when the element > > 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 more > > 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 entries > 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 memory > > usage. In this ops, the memory usage is got from the pointers which is > > already allocated by a bpf map. To make the code simple, we igore some > > 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 helpers > > are introduced firstly, for example, percpu_size(), vsize() and kvsize(). > > > > This patchset only implements the bpf memory usage for hashtab. I will > > extend it to other maps and bpf progs (bpf progs can dynamically allocate > > 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