Announcement

Collapse
No announcement yet.

New Linux System Call Proposed To Let User-Space Pin Themselves To Specific CPU Cores

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

  • New Linux System Call Proposed To Let User-Space Pin Themselves To Specific CPU Cores

    Phoronix: New Linux System Call Proposed To Let User-Space Pin Themselves To Specific CPU Cores

    A "pin_on_cpu" system call has been proposed for the Linux kernel as a new means of letting user-space threads pin themselves to specific CPU cores...

    http://www.phoronix.com/scan.php?pag...all-pin_on_cpu

  • #2
    I am curious... Is there any hardware that supports CPUs with different speeds and capabilities (extensions) of the same architecture? I see the reason for locking a task to a single CPU or CPUs but unless you can have different CPUs in multiple sockets I don't see such a need for this feature.

    http://www.dirtcellar.net

    Comment


    • #3
      Originally posted by waxhead View Post
      I am curious... Is there any hardware that supports CPUs with different speeds and capabilities (extensions) of the same architecture? I see the reason for locking a task to a single CPU or CPUs but unless you can have different CPUs in multiple sockets I don't see such a need for this feature.
      ARM big.LITTLE chips.

      Comment


      • #4
        Is it about more Bouncing cow problem?
        Htop on my desktop shows
        276 tasks and 1906 threads
        at near idle state
        on Ryzen 5 1500X

        If this helps to solve bouncing cow then it helps only when there are more cores then processes/threads on system or it is fo hard realtime task in rt_preeempt patch or RTAI/Xenomai. Can you imagine other situations this will help,please?

        3.9 Merge window part 1

        By Jonathan Corbet
        February 20, 2013
        • A relatively simple scheduler patch fixes the "bouncing cow problem," wherein, on a system with more processors than running processes, those processes can wander across the processors, yielding poor cache behavior. For a "worst-case" tbench benchmark run, the result is a 15x improvement in performance.

        https://lwn.net/Articles/538101/
        Kernel Progress On Improving I/O Wait, Interactivity
        Written by Michael Larabel in Linux Kernel on 4 March 2013


        There's also a scheduler patch to fix a "bouncing cow" problem by when running fewer processes on the system than number of processor cores, the process could be bounced around between cores and yield poor performance. This bouncing cow fix for the scheduler yields a performance boost by 15x in a worst-case scenario. More work will come to future Linux kernel releases.
        https://www.phoronix.com/scan.php?pa...tem&px=MTMxNzA

        Comment


        • #5
          Also useful with chiplets, so than an app can choose to run on only one core complex, for example.

          Comment


          • #6
            The project I'm working on spawns one thread for every core and every thread waits for a semaphore. The first thread to respond gets the task resulting in a load-balancing thread-pool since a core which is really busy doing something else will be left alone and the task gets done by the core which is less busy.

            Comment


            • #7
              Wow, this has been possible on Windows since NT 4.0, lol.

              Comment


              • #8
                Originally posted by birdie View Post
                Wow, this has been possible on Windows since NT 4.0, lol.
                This has also been possible on linux for decades, as stated in the article. This patch just adds an alternative way to do the same, with slight differences in behaviour.

                Comment


                • #9
                  Originally posted by birdie View Post
                  Wow, this has been possible on Windows since NT 4.0, lol.
                  Yea, it's been possible to set affinity, as it is called on NT as the user. But, could a program do this by itself?

                  On Linux, I think admins could have done this a while. At least it is possible with cgroups even without this new syscall.

                  Comment


                  • #10
                    Originally posted by birdie View Post
                    Wow, this has been possible on Windows since NT 4.0, lol.
                    User-space processes requesting to be run on specific CPU cores can already e done by the likes of Linux's sched_setaffinity to get/set the CPU affinity mask while pin_on_cpu would be a new and simpler way.

                    Thanks for reading the article and not posting your usual trolling bullshit.

                    Comment

                    Working...
                    X