[haiku-development] Re: On timeslices and cycles

  • From: Christian Packmann <Christian.Packmann@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 16 Mar 2009 16:00:36 +0100

Truls Becken - 2009-03-16 15:42 :
Christian Packmann wrote:

Rene Gollent - 2009-03-16 14:47 :
All it takes
is a single busy higher priority thread getting scheduled on the same
core and your careful tuning has gone out the window, since I
guarantee that it will run faster if the scheduler is able to drop it
onto an idle core on a different CPU than if it can't run at all, FSB
latency or not.
Finally, a sound technical reason against hard affinity. Thank you.

Which only becomes a problem if you run two programs using hard affinity at
the same time which try to use the same cores/threads. Otherwise the
scheduler will push the non-bound threads on the idle cores.

Doesn't this imply that threads that use hard affinity get higher
priority than any thread that doesn't? Isn't this exactly the opposite
of what you want for number crunching? The heavy lifting should run
with low priority to avoid affecting system responsiveness.

Sorry, I wasn't clear. Of course I assume that those threads will run at low priority. If they are competing with higher-pri threads on the same core, they'll get no/little time allocated. But even if you start your e.g. DC client while the core is busy with a higher-pri thread, the other thread will likely run only a short time - most user interactions don't last long in CPU time on modern systems. When the system has to do some user work again, it'll look for free cores/hw-threads first and schedule the user tasks there if possible. Otherwise they get scheduled on the bound cores/hw-threads and execute there, taking away time from your background program.


Other related posts: