Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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...nux-Scheduling

  • #2
    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"?

    Comment


    • #3
      Originally posted by OneTimeShot View Post
      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.

      Comment


      • #4
        Originally posted by OneTimeShot View Post
        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

        Comment


        • #5
          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.

          Comment


          • #6
            Originally posted by Developer12 View Post
            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.

            Comment


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

              Comment


              • #8
                Originally posted by OneTimeShot View Post
                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.

                Comment


                • #9
                  Originally posted by OneTimeShot View Post
                  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.

                  Comment


                  • #10
                    Originally posted by bug77 View Post

                    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.

                    Comment

                    Working...
                    X