obtain performance benefits by sched_setaffinity()? - Linux

This is a discussion on obtain performance benefits by sched_setaffinity()? - Linux ; Hi, I'm wondering if Linux system call sched_setaffinity() can really get performance benefits for a particular process calling it. As rest processes which don't call sched_setaffinity() will still have chances to run on the core that is dedicated to particular ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: obtain performance benefits by sched_setaffinity()?

  1. obtain performance benefits by sched_setaffinity()?

    Hi,

    I'm wondering if Linux system call sched_setaffinity() can really get
    performance benefits for a particular process calling it. As rest
    processes which don't call sched_setaffinity() will still have
    chances to run on the core that is dedicated to particular process,
    unless all processes in Linux calls sched_setaffinity(). However,
    there are lot of kernel thread and system service processes are
    running in the Linux system, then only one process calls
    sched_setaffinity() and want to improve the performance, it looks
    impossible. If my understanding is right?

    CY.

  2. Re: obtain performance benefits by sched_setaffinity()?

    cyril.li@gmail.com wrote:
    > Hi,
    >
    > I'm wondering if Linux system call sched_setaffinity() can really get
    > performance benefits for a particular process calling it. As rest
    > processes which don't call sched_setaffinity() will still have
    > chances to run on the core that is dedicated to particular process,
    > unless all processes in Linux calls sched_setaffinity(). However,
    > there are lot of kernel thread and system service processes are
    > running in the Linux system, then only one process calls
    > sched_setaffinity() and want to improve the performance, it looks
    > impossible. If my understanding is right?


    You can also set the priority of the affined task such that it is more
    important than the other tasks.

    As an example we have a deployed system where all the interrupts are
    affined to one cpu, most I/O is processed on that cpu, and the bulk of
    the processing is done on the other cpu. This involves extensive use of
    cpu affinity.

    Chris

  3. Re: obtain performance benefits by sched_setaffinity()?

    On Sep 24, 6:28*am, "cyril...@gmail.com" wrote:

    > I'm wondering if Linux system call sched_setaffinity() can really get
    > performance benefits for a particular process calling it. As rest
    > processes which don't call sched_setaffinity() *will still have
    > chances to run on the core that is dedicated to particular process,
    > unless all processes in Linux calls sched_setaffinity(). However,
    > there are lot of kernel thread and system service processes are
    > running in the Linux system, then only one process calls
    > sched_setaffinity() and want to improve the performance, it looks
    > impossible. If my understanding is right?


    It's very tricky to get this to be helpful. For example, suppose your
    process is bound to one CPU by affinity. If that process is not ready-
    to-run, that CPU will be used for other things. Then if the process
    does become ready-to-run, it won't be scheduled until that CPU can be
    commandeered, even if other CPUs are currently available. This can
    significantly worsen your average scheduling latency.

    Even if you reserve a CPU just for a task, you still may make things
    worse. For example, if an interrupt is served on CPU0 that unblocks a
    task, the data may be hot in CPU0's cache. But if you bound the
    process to CPU1 so it wouldn't compete with the interrupt, you now
    force the data to migrate over the FSB.

    You really need to know exactly what you're doing, know more than the
    scheduler, and have fairly complete control over large subsets of the
    system for CPU affinity to do you more good than harm.

    You can elevate priority. You can reserve a CPU such that only your
    task is allowed to use it. But you still (probably) don't want to bind
    your task to just that CPU. That only reduces scheduling options.

    DS

  4. Re: obtain performance benefits by sched_setaffinity()?

    David Schwartz wrote:

    > You really need to know exactly what you're doing, know more than the
    > scheduler, and have fairly complete control over large subsets of the
    > system for CPU affinity to do you more good than harm.


    Yes, absolutely. As I mentioned, we have a system that makes use of
    affinity to good effect, but it required careful engineering and validation.

    Chris

  5. Re: obtain performance benefits by sched_setaffinity()?

    On 9月25日, 上午3时04分, Chris Friesen wrote:
    > David Schwartz wrote:
    > > You really need to know exactly what you're doing, know more than the
    > > scheduler, and have fairly complete control over large subsets of the
    > > system for CPU affinity to do you more good than harm.

    >
    > Yes, absolutely. As I mentioned, we have a system that makes use of
    > affinity to good effect, but it required careful engineering and validation.
    >
    > Chris


    It seems that to make one core completely reserve for one process,
    need sched_setaffinity() + priority

  6. Re: obtain performance benefits by sched_setaffinity()?

    cyril.li@gmail.com wrote:

    > It seems that to make one core completely reserve for one process,
    > need sched_setaffinity() + priority


    Nope. Affine one process one one core, and affine all other processes
    to the other core(s).

    Chris

  7. Re: obtain performance benefits by sched_setaffinity()?

    On Sep 26, 10:54*pm, Chris Friesen wrote:
    > cyril...@gmail.com wrote:
    > > It seems that to make one core completely reserve for one process,
    > > need sched_setaffinity() + priority

    >
    > Nope. *Affine one process one one core, and affine all other processes
    > to the other core(s).
    >
    > Chris


    Then how to handle the default Linux daemons? How to pin these Linux
    service daemon to all other cores?

    CY

+ Reply to Thread