[haiku-development] Re: On timeslices and cycles
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 14 Mar 2009 10:50:53 +0100
-------- Original-Nachricht --------
> Datum: Sat, 14 Mar 2009 01:59:58 +0100
> Von: Ingo Weinhold <ingo_weinhold@xxxxxx>
> An: haiku-development@xxxxxxxxxxxxx
> Betreff: [haiku-development] Re: On timeslices and cycles
>
> 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.
+1, I guess it depends a bit on the specific project's goals, but I tend to
agree. I don't know what benefit it has to prove that a couple thousand
computers (or millions?) can crack some 512 bit key in a couple months, which
seems to be what some projects are about.
-Stephan
Other related posts:
