50 ms·

Since we’re talking the scheduler, has it gotten better at not ping-ponging processors around? I seem to remember years ago I could open activity monitor and w

by MBCook 3y ago

Since we’re talking the scheduler, has it gotten better at not ping-ponging processors around? I seem to remember years ago I could open activity monitor and watch processes migrate back-and-forth between cores for seemingly no reason instead of just sticking in places. I haven’t watched to see what happens recently. Is that still an issue?

3cats-in-a-coat 3y ago
Aside from cosmetics, is it really an issue? And why?
- MBCook 3y ago
  Depending on which cores it’s moving between it could be a performance issue if they don’t share a cache. I don’t know if it actually is or was.
- serf 3y ago
  It causes latency issues on SMP machines with multiple processors for sure; I don't know whether or not that same issue translates to a similar scheduling problem across the same die, although I imagine it would, the context switch and scheduler itself isn't costless. gamers have been binding to single processors/cores for years for that reason, it's a huge cause of microstutter type behaviors -- but who knows if its perceivable with all the magic going on with processors nowadays.
  - aeadio 3y ago
    Processes get interrupted and rescheduled between tens and hundreds of times per second (depending on OS, the scheduler may take over somewhere between 100 and 2000 Hz, although it doesn't necessarily deschedule every time). This is how SMP works at its most fundamental level. Every time that happens, it involves a full flush from the hardware perspective. It's always context switching, savings the registers, clearing the buffers, etc. When a process gets descheduled and then later rescheduled, there is no particular reason to reschedule it on the same core it was on previously. Desktop class hardware doesn't have NUMA. Last level caches might have locality-dependent performance characteristics, but this is usually pretty nuanced, wildly variable between hardware microarchitectures, and not accounted for / not worth accounting for in the OS's scheduler, since there's a good chance that data won't be around next timeslice anyway. Binding a processor to a single core affinity-wise is not changing any of this. If you really have a throughput-bound process that needs to squeeze every single microsecond of compute and/or you're super latency bound for some reason, you schedule a process with what's called realtime priority, which changes the scheduling decision of WHEN to deschedule it. Not every operating system has equivalent mechanisms for this, but that's more in line with the phenomena that you're describing. But a process may well cause itself to be descheduled anyway by doing something that puts it to sleep. You have no control over this. In reality, looking at which core a process is on is mostly the wrong way to be thinking. You're looking at this on a 1-2 second window (the amount of time it takes for Activity Monitor / Task Manager to update its UI). A full second of time is an absolute eternity to a process. Large amounts of work happen on the order of microseconds and quicker. And in that 1-2 second snapshot that Activity Monitor or Task Manager gave you, the process probably spent time on EVERY core -- and you're just seeing wherever it was in the brief moment when Activity Monitor / Task Manager updated its UI. > gamers have been binding to single processors/cores for years for that reason, it's a huge cause of microstutter type behaviors It wouldn't be the first time gamers prescribed placebo tweaks because of magical type thinking.
    - sroussey 3y ago
      Desktops have mini-numa (core complex et al), and a scheduler might take this into account, but I think the cache lines are emptied anyhow on context switch, but otherwise multi threaded apps might be able to share some cache. Or it might not, and it will thrash the cache and be better in different complexes. Easy to contemplate opposite scenarios.
deleted 3y ago
[deleted]
kiririn 3y ago
Reason for it is thermals
krackers 3y ago
How can you see which core a process in on from activity monitor? Only way I know of is via instruments?
- MBCook 3y ago
  I think it was back when I ran a utility called MenuMeters which no longer exists. iStatMenus is a similar utility that still exists and is far more popular.
  - krackers 3y ago
    istat menus doesn't show you _which_ core a given process is running on though? It only shows you total core activity?
    - deleted 3y ago
      [deleted]

by MBCook 3y ago

3cats-in-a-coat 3y ago

Aside from cosmetics, is it really an issue? And why?

MBCook 3y ago
Depending on which cores it’s moving between it could be a performance issue if they don’t share a cache. I don’t know if it actually is or was.
serf 3y ago
It causes latency issues on SMP machines with multiple processors for sure; I don't know whether or not that same issue translates to a similar scheduling problem across the same die, although I imagine it would, the context switch and scheduler itself isn't costless. gamers have been binding to single processors/cores for years for that reason, it's a huge cause of microstutter type behaviors -- but who knows if its perceivable with all the magic going on with processors nowadays.
- aeadio 3y ago
  Processes get interrupted and rescheduled between tens and hundreds of times per second (depending on OS, the scheduler may take over somewhere between 100 and 2000 Hz, although it doesn't necessarily deschedule every time). This is how SMP works at its most fundamental level. Every time that happens, it involves a full flush from the hardware perspective. It's always context switching, savings the registers, clearing the buffers, etc. When a process gets descheduled and then later rescheduled, there is no particular reason to reschedule it on the same core it was on previously. Desktop class hardware doesn't have NUMA. Last level caches might have locality-dependent performance characteristics, but this is usually pretty nuanced, wildly variable between hardware microarchitectures, and not accounted for / not worth accounting for in the OS's scheduler, since there's a good chance that data won't be around next timeslice anyway. Binding a processor to a single core affinity-wise is not changing any of this. If you really have a throughput-bound process that needs to squeeze every single microsecond of compute and/or you're super latency bound for some reason, you schedule a process with what's called realtime priority, which changes the scheduling decision of WHEN to deschedule it. Not every operating system has equivalent mechanisms for this, but that's more in line with the phenomena that you're describing. But a process may well cause itself to be descheduled anyway by doing something that puts it to sleep. You have no control over this. In reality, looking at which core a process is on is mostly the wrong way to be thinking. You're looking at this on a 1-2 second window (the amount of time it takes for Activity Monitor / Task Manager to update its UI). A full second of time is an absolute eternity to a process. Large amounts of work happen on the order of microseconds and quicker. And in that 1-2 second snapshot that Activity Monitor or Task Manager gave you, the process probably spent time on EVERY core -- and you're just seeing wherever it was in the brief moment when Activity Monitor / Task Manager updated its UI. > gamers have been binding to single processors/cores for years for that reason, it's a huge cause of microstutter type behaviors It wouldn't be the first time gamers prescribed placebo tweaks because of magical type thinking.
  - sroussey 3y ago
    Desktops have mini-numa (core complex et al), and a scheduler might take this into account, but I think the cache lines are emptied anyhow on context switch, but otherwise multi threaded apps might be able to share some cache. Or it might not, and it will thrash the cache and be better in different complexes. Easy to contemplate opposite scenarios.

deleted 3y ago

[deleted]

kiririn 3y ago

Reason for it is thermals

krackers 3y ago

How can you see which core a process in on from activity monitor? Only way I know of is via instruments?

MBCook 3y ago
I think it was back when I ran a utility called MenuMeters which no longer exists. iStatMenus is a similar utility that still exists and is far more popular.
- krackers 3y ago
  istat menus doesn't show you _which_ core a given process is running on though? It only shows you total core activity?
  - deleted 3y ago
    [deleted]