All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Hao Luo <haoluo@google.com>
Cc: "Hao Xiang ." <hao.xiang@bytedance.com>,
	bpf@vger.kernel.org, Chuang <horenchuang@bytedance.com>,
	Yifei Ma <yifeima@bytedance.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>
Subject: Re: Questions about querying map object information
Date: Tue, 12 Jul 2022 10:53:24 +0200	[thread overview]
Message-ID: <Ys02hDIYZ58kYTNf@krava> (raw)
In-Reply-To: <CA+khW7gMsE1iqmzibvHUCMUvfD5Rku46GaazwyvktGnHennDxg@mail.gmail.com>

On Mon, Jul 11, 2022 at 04:35:19PM -0700, Hao Luo wrote:
> Hi Hao Xiang,
> 
> On Mon, Jul 11, 2022 at 3:50 PM Hao Xiang . <hao.xiang@bytedance.com> wrote:
> >
> > Ping...
> >
> > Can someone please help to shed some light on this?
> >
> > Thanks, Hao
> >
> > On Sun, Jul 3, 2022 at 3:33 PM Hao Xiang . <hao.xiang@bytedance.com> wrote:
> > >
> > > Hi everyone,
> > >
> > > I am super new to bpf and the open source community in general. Please
> > > bear with me asking some basic questions.
> > > We are working on a bpf monitoring tool to track the CPU and memory
> > > usage for all bpf programs loaded in the system. We were able to get
> > > CPU usage per bpf program with the BPF_OBJ_GET_INFO_BY_ID syscall on a
> > > bpf prog object. We are trying to do the same on a map object to query
> > > for per map memory usage. The information returned from bpf_map_info
> > > only contains things like max_entries, key_size, value_size, which can
> > > be used to calculate estimated memory allocation size. But we are also
> > > interested in knowing how much memory is actually being used by our
> > > program. For instance, one of our bpf program uses a map with type
> > > hashtable. The hashtable is created with a chunk of pre-allocated
> > > memory based on the max_entres, key_size and value size. The
> > > pre-allocated size is useful information to know but so is the current
> > > number of entries in the hashtable. We used to run into a performance
> > > issue where our bpf map's max_entries is set to be too small and we
> > > end up totally exhausting the pre-allocated memory. So knowing things
> > > like current entry count VS max entry count of a hashtable is useful
> > > information for us.
> > > With that being said, we have a few questions and hopefully we can get
> > > some help from the community.
> > > 1) We couldn't find anything in bpf_map_info to give us the current
> > > entry count of a hashtable. I read that bpf_map_info returns
> > > information about a map object in general. So it makes total sense to
> > > not have information of a particular map type. But is there an
> > > existing place we can get the per map type information (eg, the
> > > current entry count of a hashtable, the number of elements pushed to a
> > > stack, etc)?
> 
> cc more BPF experts for their comments.
> 
> I agree with you that knowing the current space usage of a map is
> quite helpful. In my understanding, a naive and inefficient way to
> estimate space usage is iterating the map and counting the map
> elements. That's doable, but may not be the best method though.
> Regarding auto-adjusting map size, I remember Andrii talked about
> resizable hash maps, maybe he can tell you more [1].

we keep entries count for hash map, maybe we could just add
'current count' to bpf_map_info, it seems generic enough

jirka

> 
> [1] http://vger.kernel.org/bpfconf2022_material/lsfmmbpf2022-algs.pdf
> 
> > > 2) If there isn't an existing place to return map type specific
> > > information, would it make sense to extend the structure bpf_map_info
> > > with a union at the end and have that union to contain per map type
> > > specific information?
> > >
> > > Thanks, Hao

  parent reply	other threads:[~2022-07-12  8:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-03 22:33 Questions about querying map object information Hao Xiang .
2022-07-11 22:50 ` Hao Xiang .
2022-07-11 23:35   ` Hao Luo
2022-07-12  0:46     ` [External] " Hao Xiang .
2022-07-12  8:53     ` Jiri Olsa [this message]
2022-07-12 16:04       ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ys02hDIYZ58kYTNf@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hao.xiang@bytedance.com \
    --cc=haoluo@google.com \
    --cc=horenchuang@bytedance.com \
    --cc=john.fastabend@gmail.com \
    --cc=yifeima@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.