[haiku-development] Re: On timeslices and cycles
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 13 Mar 2009 13:41:38 +0100
On 2009-03-13 at 13:08:37 [+0100], Christian Packmann
<Christian.Packmann@xxxxxx> wrote:
> Axel Dörfler - 2009-03-13 12:28 :
> > Christian Packmann <Christian.Packmann@xxxxxx> wrote:
> >> Oh, and fixing CPU affinity would also allow me for writing proper
> >> benchmarking tools without having to worry about core hopping, so I'm
> >> not
> >> quite neutral in this matter. ;-)
> >
> > CPU affinity does not avoid CPU hopping - it just makes it happen much
> > less often.
>
> You're talking about soft affinity, which should be an inherent part of a
> good scheduler - try to keep a thread on the same CPU as long as possible.
> Affinity settable by OS calls usually is hard affinity, i.e. the thread
> will run only on the given CPU(s), when multiple CPUs are given in the
> affinity mask, the OS is free to schedule the thread on any of the CPUs as
> it sees fit.
>
> A good introduction to this for Linux:
> http://www.linuxjournal.com/article/6799
>
> And hard affinity is a requirement in some cases. E.g. when I want to get
> reliable Time Stamp Counters (or PMC) measurements on a Barcelona/Phenom,
> I need to use hard CPU affinity for a single core, as the CPUs will have
> varying frequencies and thus TSCs per core. I'm currently considering just
> switching off all CPUs/cores but one on Haiku, as this is the only way to
> get reliable measurements.
From what I've read so far, pretty much the only good use for hard affinity
is for performance measurements. When pinning a thread to one CPU you
prevent it from running when this CPU is busy, even if another CPU is idle
at the same time. While CPU hopping is certainly not good, not running is
usually even worse. Soft affinity seems to be the best strategy in finding
a good compromise, though it's not trivial to implement.
IMHO, leaving scheduling decisions to application developers is certainly a
bad choice (cooperative multitasking, anyone?). Allowing them to give the
OS hints, how their threads will behave wrt. to CPU, memory, I/O usage,
might be useful, though.
CU, Ingo
Other related posts:
