Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

[Tejun Heo]

Hello, Peter.

On Mon, Jun 24, 2024 at 11:34:26AM +0200, Peter Zijlstra wrote:
> I'm confused. Once you've loaded the BPF thing, 'all' tasks you care
> about should already be in the bpf class. So any fork() thereafter
> should not need to switch classes.
> 
> This means we can have this rwsem be strictly for the bpf tasks as
> Thomas suggested.
> 
> What are we missing?

Maybe I am confused but let's say the BPF scheduler gets unloaded and
reloaded. What would prevent a forking thread which didn't acquire the read
lock from racing against the second loading?

Also, let's say we can make it conditional but would the extra complication
be justifiable? percpu_down_read()'s hot path is one likely() cond test
followed by this_cpu_inc() wrapped in preempt_disable(). I'm not really sure
eliding that can justify much.

That said, as Thomas pointed out, the dl cancel path is silly. Let me clean
that up.

Thanks.

-- 
tejun