On Tue, Jul 28, 2020 at 12:09 PM Roman Gushchin <guro@xxxxxx> wrote: > > On Mon, Jul 27, 2020 at 11:06:42PM -0700, Song Liu wrote: > > On Mon, Jul 27, 2020 at 10:58 PM Andrii Nakryiko > > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > On Mon, Jul 27, 2020 at 10:47 PM Song Liu <song@xxxxxxxxxx> wrote: > > > > > > > > On Mon, Jul 27, 2020 at 12:26 PM Roman Gushchin <guro@xxxxxx> wrote: > > > > > > > > > > Remove rlimit-based accounting infrastructure code, which is not used > > > > > anymore. > > > > > > > > > > Signed-off-by: Roman Gushchin <guro@xxxxxx> > > > > [...] > > > > > > > > > > static void bpf_map_put_uref(struct bpf_map *map) > > > > > @@ -541,7 +484,7 @@ static void bpf_map_show_fdinfo(struct seq_file *m, struct file *filp) > > > > > "value_size:\t%u\n" > > > > > "max_entries:\t%u\n" > > > > > "map_flags:\t%#x\n" > > > > > - "memlock:\t%llu\n" > > > > > + "memlock:\t%llu\n" /* deprecated */ > > > > > > > > I am not sure whether we can deprecate this one.. How difficult is it > > > > to keep this statistics? > > > > > > > > > > It's factually correct now, that BPF map doesn't use any memlock memory, no? > > Right. > > > > > I am not sure whether memlock really means memlock for all users... I bet there > > are users who use memlock to check total memory used by the map. > > But this is just the part of struct bpf_map, so I agree with Andrii, > it's a safe check. > > > > > > > > > This is actually one way to detect whether RLIMIT_MEMLOCK is necessary > > > or not: create a small map, check if it's fdinfo has memlock: 0 or not > > > :) > > > > If we do show memlock=0, this is a good check... > > The only question I have if it's worth checking at all? Bumping the rlimit > is a way cheaper operation than creating a temporarily map and checking its > properties. > for perf and libbpf -- I think it's totally worth it. Bumping RLIMIT_MEMLOCK automatically means potentially messing up some other parts of the system (e.g., BCC just bumps it to INFINITY allowing to over-allocate too much memory, potentially, for unrelated applications that do rely on RLIMIT_MEMLOCK). It's one of the reasons why libbpf doesn't do it automatically, actually. So knowing when this is not necessary, will allow to improve diagnostic messages by libbpf, and would just avoid potentially risky operation by perf/BCC/etc. > So is there any win in comparison to just leaving the userspace code* as it is > for now? > > * except runqslower and samples
