Re: Pinning IO Thread to a particular processor
Re: Pinning IO Thread to a particular processor
- Subject: Re: Pinning IO Thread to a particular processor
- From: Jeff Moore <email@hidden>
- Date: Mon, 30 Jan 2006 16:01:48 -0800
I should add that Mr. Wexler's comment about VM is something to look
at with respect to the original problem. It's entirely possible that
there is some bit of memory getting evicted at the wrong time causing
a page fault on the IO thread. I don't recall the original post
mentioning anything about the sort of memory pressure the machine is
under. I think it just says that the CPUs are fairly heavily loaded.
On Jan 30, 2006, at 3:52 PM, Jeff Moore wrote:
Recall the situation that Mr. Haller was describing. You have a
very fast, 4 CPU machine and one thread that is trying to meat a
deadline that is probably less than 2 milliseconds. We're talking
about a machine that can reload a cache line in a handful of
microseconds. We're not talking about VM page faults here, just
fetching stuff from main memory. G5's have fast main memory.
Compare that with going from an average of sub-10 microsecond
scheduling latency for multiple CPUs vs. the 100-200 microseconds
you will see with just one processor. And it could be worse if the
CPU to which you have been pinned just happens to get monopolized
by somebody else.
So, you end up trading a modest amount of overhead for a lot of
overhead. This trade is really only going to be worth while if you
are moving a lot of memory around on the IO thread. Since you can
only get into this situation by setting the IO buffer size fairly
small, you are by definition lowering your memory usage from the
get go. Also, given the relative dearth of cache on the G5, if you
are moving lots of memory on the IO thread, chances are you are
already thrashing the caches pretty severely anyway so you will
actually hurt your performance more by pinning the thread to a
particular CPU and incurring the additional scheduling latency.
There are always trade offs to keep in mind when exploring things
like this. Sometimes they are not obvious and you can easily save a
little time in one spot while spending a bit more somewhere else.
On Jan 30, 2006, at 3:21 PM, Shaun Wexler wrote:
On Jan 30, 2006, at 11:41 AM, Jeff Moore wrote:
I don't know that the scheduler has a notion of processor
affinity. Even if it did, the HAL owns the thread and as such it
can come and go ou from under you.
At any rate, while bouncing around between processors can cause
caches thrash a bit more often, there isn't exactly a whole lot
of cache on a G5 anyway. So the effect wouldn't be as pronounced.
Besides, when you pin a thread to a particular processor, you are
trading cache coherency for increased scheduling latency. As the
IO buffer size gets smaller, the scheduling latency, which is
generally always the same, will take an increasing amount of the
available time. So, I'm not sure that the trade off would
actually result in better performance.
Another issue the Quad might be susceptible to could be related to
the shared 2MB cache of each dual-core chip. It's possible that a
thread running on "Core B" could evict data from "Core A's" cache,
forcing its HAL thread to stumble out to main memory for every
bit. Worst-case scenario, it might also be paging, blocking the
IOProc. Maybe he's not wired-down when/where he needs to be? ;)
--
Jeff Moore
Core Audio
Apple
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden