From: Jesper Dangaard Brouer <brouer@redhat.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: daniel@iogearbox.net, ast@fb.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, brouer@redhat.com,
Roman Gushchin <guro@fb.com>,
kernel-team@fb.com
Subject: Re: [PATCH bpf] samples/bpf: Set rlimit for memlock to infinity in all samples
Date: Tue, 27 Oct 2020 08:14:40 +0100 [thread overview]
Message-ID: <20201027081440.756cd175@carbon> (raw)
In-Reply-To: <20201026233623.91728-1-toke@redhat.com>
On Tue, 27 Oct 2020 00:36:23 +0100
Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> The memlock rlimit is a notorious source of failure for BPF programs. Most
> of the samples just set it to infinity, but a few used a lower limit. The
> problem with unconditionally setting a lower limit is that this will also
> override the limit if the system-wide setting is *higher* than the limit
> being set, which can lead to failures on systems that lock a lot of memory,
> but set 'ulimit -l' to unlimited before running a sample.
>
> One fix for this is to only conditionally set the limit if the current
> limit is lower, but it is simpler to just unify all the samples and have
> them all set the limit to infinity.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
This change basically disable the memlock rlimit system. And this
disable method is becoming standard in more and more BPF programs.
IMHO using the system-wide memlock rlimit doesn't make sense for BPF.
I'm still ACKing the patch, as this seems the only way forward, to
ignore and in-practice not use the memlock rlimit.
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
I saw some patches on the list (from Facebook) with a new system for
policy limiting memory usage per BPF program or was it mem-cgroup, but
I don't think that was ever merged... I would really like to see
something replace (and remove) this memlock rlimit dependency. Anyone
knows what happened to that effort?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2020-10-27 7:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 23:36 [PATCH bpf] samples/bpf: Set rlimit for memlock to infinity in all samples Toke Høiland-Jørgensen
2020-10-27 3:52 ` Andrii Nakryiko
2020-10-27 7:14 ` Jesper Dangaard Brouer [this message]
2020-10-27 17:00 ` Roman Gushchin
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=20201027081440.756cd175@carbon \
--to=brouer@redhat.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=guro@fb.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.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.