[haiku-development] Re: On timeslices and cycles
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 14 Mar 2009 01:59:58 +0100
On 2009-03-13 at 17:03:44 [+0100], Urias McCullough <umccullough@xxxxxxxxx>
wrote:
> On Fri, Mar 13, 2009 at 5:41 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2009-03-13 at 13:08:37 [+0100], Christian Packmann
> >> 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.
>
> Well, at least most distributed computing apps make use of CPU
> affinity (both hard and soft) - since the primary purpose of such apps
> is to crunch as hard as possible, it's generally desirable to fix each
> thread to a single core. These apps are generally designed to run at
> lowest or idle priority so any thread in the system can run over the
> top of them. It is not at all desirable to let the thread migrate, as
> there is actually no intention to run the thread when the specific cpu
> is busy, nor do all threads being run require equal time. Thus some
> threads will finish a bit earlier than others, and that's generally
> acceptable - and not just on that particular computer since worker
> threads for the same project are running on hundreds of thousands of
> computers worldwide. :)
>
> I bring this up because in the hardcore distributed computing camp,
> the developers and users alike, are always seeking out new ways to
> make their client apps run faster on each target OS, and OSes with
> "weak" threading control are usually avoided. Most of these
> applications have even user-configurable control over the affinity and
> thread count.
This doesn't convince me, that hard affinity is needed for this purpose. In
case the computer is mostly idle -- which I guess is the case most of the
time -- soft affinity will result in the same scheduling as pinning the
threads manually to the CPUs. In case the computer is fully busy (like
compiling on all CPUs), the low priority threads won't run, so the behavior
will be the same as well. For the inbetween cases I have no idea what will
happen. This will mainly depend on CPU and memory usage of the involved
threads.
Anyway, introducing hard affinity -- which guaranteedly will be abused by
application developers who think they know what they are doing -- so that
people can squeeze 0.01% more throughput for distributed applications out of
their machines seems hardly a good bargain. Besides, from an environmental
point of view, I'm not even sure I still like those projects.
> Before you suggest that Haiku isn't targeting distributed computing, I
> will point out that the vast majority of of the work done for
> public-run distributed computing projects are done with Windows XP at
> this point.
Wildly guessing I'd say Windows XP is the most widely used OS, so that sounds
hardly surprising. :-)
CU, Ingo
Other related posts:
