BPF List
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH rfc 0/6] Scheduler BPF
Date: Fri, 26 Nov 2021 11:46:44 -0800	[thread overview]
Message-ID: <YaE5pDv5OhkAC+a4@carbon.dhcp.thefacebook.com> (raw)
In-Reply-To: <CALOAHbC0xNnqWt=og+g=DT0yRqST6cTAUvZkQ-7o8Nw8O-2J9w@mail.gmail.com>

On Thu, Nov 25, 2021 at 02:00:04PM +0800, Yafang Shao wrote:
> Hi Roman,

Hi Yafang!

> 
> Scheduler BPF is a great idea.
> Thanks for the work.

Thanks!

> 
> Scheduler BPF won’t be a small feature,  I think we’d better give a
> summary of possible hooks it may add first.
> We must have a *basic rule* to control what it will tend to be to
> avoid adding BPF hooks here and there.
> I haven’t found a clear rule yet, but maybe we can learn it from
> netfilter, which has 5 basic hooks.
> Regarding the scheduler BPF hooks, some possible basic hooks may be:
>   - Hook for Enqueue
>   - Hook for Dequeue
>   - Hook for Put Prev Task
>    - Hook for Set Next Task

I think it depends on what we want to achieve. There are several options:
we might aim to implement the whole scheduler logic in bpf, we might aim
to do some adjustments to the existing scheduler behavior or a mix of those
approaches.

Bpf as now is now is not capable enough to implement a new scheduler class
without a substantial amount of new c code (in form of helpers, maybe custom
maps, some verifier changes etc). In particular, it's a challenging to
provide strong safety guarantees: any scheduler bpf program loaded shouldn't
crash or deadlock the system (otherwise bpf isn't any better than a kernel
module). Also performance margins are quite tight.

I'm not saying that providing such generic hooks is impossible or useless,
but it requires a lot of changes and support code and I'm not sure that we have
a good justification for them right now.

I think instead we might want to see bpf hooks as a better form of (sysctl)
tunables, which are more flexible (e.g. can be used for specific processes,
cgroups, cpus, being enabled depending on load, weather, etc) and do not create
an ABI (so are easier to maintain).

> 
> 
> > An example of an userspace part, which loads some simple hooks is available
> > here [3]. It's very simple, provided only to simplify playing with the provided
> > kernel patches.
> >
> 
> You’d better add this userspace code into samples/bpf/.

I thought samples/bpf was considered deprecated (in favor to selftests/bpf/),
but I'm gonna check with bpf maintainers. Thanks for the idea!

  reply	other threads:[~2021-11-26 19:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210915213550.3696532-1-guro@fb.com>
2021-09-16  0:19 ` [PATCH rfc 0/6] Scheduler BPF Hao Luo
2021-09-16  1:42   ` Roman Gushchin
2021-09-16 16:24 ` Roman Gushchin
2021-09-16 16:24   ` [PATCH rfc 1/6] bpf: sched: basic infrastructure for scheduler bpf Roman Gushchin
2021-09-16 16:24   ` [PATCH rfc 2/6] bpf: sched: add convenient helpers to identify sched entities Roman Gushchin
2021-11-25  6:09     ` Yafang Shao
2021-11-26 19:50       ` Roman Gushchin
2021-09-16 16:24   ` [PATCH rfc 3/6] bpf: sched: introduce bpf_sched_enable() Roman Gushchin
2021-09-16 16:24   ` [PATCH rfc 4/6] sched: cfs: add bpf hooks to control wakeup and tick preemption Roman Gushchin
2021-10-01  3:35     ` Barry Song
2021-10-02  0:13       ` Roman Gushchin
2021-09-16 16:24   ` [PATCH rfc 5/6] libbpf: add support for scheduler bpf programs Roman Gushchin
2021-09-16 16:24   ` [PATCH rfc 6/6] bpftool: recognize scheduler programs Roman Gushchin
2021-09-16 16:36   ` [PATCH rfc 0/6] Scheduler BPF Roman Gushchin
2021-10-06 16:39   ` Qais Yousef
2021-10-06 18:50     ` Roman Gushchin
2021-10-11 16:38       ` Qais Yousef
2021-10-11 18:09         ` Roman Gushchin
2021-10-12 10:16           ` Qais Yousef
     [not found]   ` <52EC1E80-4C89-43AD-8A59-8ACA184EAE53@gmail.com>
2021-11-25  6:00     ` Yafang Shao
2021-11-26 19:46       ` Roman Gushchin [this message]
2022-01-15  8:29   ` Huichun Feng
2022-01-18 22:54     ` Roman Gushchin
2022-07-19 13:05   ` Ren Zhijie
2022-07-19 13:17   ` Ren Zhijie
2022-07-19 23:21     ` Roman Gushchin
2021-11-20 16:41 Hui-Chun Feng

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=YaE5pDv5OhkAC+a4@carbon.dhcp.thefacebook.com \
    --to=guro@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox