Google's Ghost Look Very Appealing For Kernel Scheduling From User-Space & eBPF Programs

[phoronix]

Phoronix: Google's Ghost Look Very Appealing For Kernel Scheduling From User-Space & eBPF Programs

Google for quite some time now has been working on "Ghost" as a means of controlling the Linux kernel scheduler from user-space and/or eBPF programs. Ghost provides an extensive API so developers can alter the kernel's scheduler behavior from user-space or eBPF and fine-tune the scheduling behavior based on system preferences...

https://www.phoronix.com/news/Google-Ghost-Linux-Scheduling

[OneTimeShot]

I wonder how useful this is going to be in practice? If you're on a general purpose computer, this is going to be far too complex for a user to configure. If you're in a "need to squeeze every CPU cycle out" scenario then you probably just have a specialised task that you're running over a compute farm and the scheduler isn't really doing anything special...

I guess potentially you could have a system broken into multiple programs with lots of IPC that make it inefficient... but then maybe "fix the real issue"?

[Jakobson]

I wonder how useful this is going to be in practice? If you're on a general purpose computer, this is going to be far too complex for a user to configure. If you're in a "need to squeeze every CPU cycle out" scenario then you probably just have a specialised task that you're running over a compute farm and the scheduler isn't really doing anything special...

Google's initial focus on implementation has been data centers.

[kalin]

I wonder how useful this is going to be in practice? If you're on a general purpose computer, this is going to be far too complex for a user to configure. If you're in a "need to squeeze every CPU cycle out" scenario then you probably just have a specialised task that you're running over a compute farm and the scheduler isn't really doing anything special...

I guess potentially you could have a system broken into multiple programs with lots of IPC that make it inefficient... but then maybe "fix the real issue"?

Gamemode like services ? There many demanding application that can use such a thing while they work on foreground

[Developer12]

Why in the world would you move CFS into BPF? It's much faster written in C as part of the core kernel code and everybody uses it. It's not some ultra-specialized scheduling algorithm that you might want to swap out.

[NobodyXu]

Why in the world would you move CFS into BPF? It's much faster written in C as part of the core kernel code and everybody uses it. It's not some ultra-specialized scheduling algorithm that you might want to swap out.

My guess is that it would be a good exercise to see how Ghost would work in practice and what kind of API/features it is lacking and how it performs compared to in-kernel C implementation.

[guglovich]

eBPF will soon become the kernel and Linux will be just a shell around it.

[bug77]

I wonder how useful this is going to be in practice? If you're on a general purpose computer, this is going to be far too complex for a user to configure. If you're in a "need to squeeze every CPU cycle out" scenario then you probably just have a specialised task that you're running over a compute farm and the scheduler isn't really doing anything special...

I guess potentially you could have a system broken into multiple programs with lots of IPC that make it inefficient... but then maybe "fix the real issue"?

I imagine the user continues to configure basic stuff like "max perf", "power save". Only the underlying logic, together with hints from applications, becomes smarter.

[blitz120]

I wonder how useful this is going to be in practice? If you're on a general purpose computer, this is going to be far too complex for a user to configure. If you're in a "need to squeeze every CPU cycle out" scenario then you probably just have a specialised task that you're running over a compute farm and the scheduler isn't really doing anything special...

I guess potentially you could have a system broken into multiple programs with lots of IPC that make it inefficient... but then maybe "fix the real issue"?

If Ghost can alter priorities for a thread quickly enough, it could be quite useful to minimize conflicts while holding user space mutexes. I can certainly see where acquiring a mutex, raising the priority, performing the serialized action, releasing the mutex and restoring the priority could both reduce elapsed time and the number of iterations in a spinlock.

[blitz120]

I imagine the user continues to configure basic stuff like "max perf", "power save". Only the underlying logic, together with hints from applications, becomes smarter.

I would expect this API to be used primarily by low-level or "systems" programmers and encapsulated in libraries used by applications.