Re: More Glitches
Re: More Glitches
- Subject: Re: More Glitches
- From: Jeff Moore <email@hidden>
- Date: Tue, 15 Feb 2005 12:36:34 -0800
What you are talking about is an arms race, especially since there are
other real time threads on the system that will also want to compete
for the CPU. Sure we could mark the HAL's IO thread as special somehow,
but what about the threads that it directly depends on (e.g. the
FireWire callback thread in the driver)? You quickly get to the point
where every thread is special again.
The kernel does do it's best to keep VM paging out of the way, but it's
a tricky and ongoing job. The situation you mention with samplers is a
case in point. The sample data is going to want to be used on the IO
thread, so you'll get paging there if the machine is under memory
pressure.
As for looking for paging activity, I just use the standard Shark
profile for collecting memory stats. There's one in particular for
tracking page-in faults. For me, it just shows up in the profile combo
box when I launch the app.
On Feb 15, 2005, at 12:18 PM, Jeremy Sagan wrote:
Jeff,
Thank you for your answer which is very helpful. However I still have
some questions....
On Feb 15, 2005, at 2:36 PM, Jeff Moore wrote:
The VM Pager is one of the few threads that are actually higher
priority than a time constraint thread like what the HAL uses for IO
threads. So, if you have another thread that is page faulting, it
can and will interfere with the performance of the IO thread,
usually by pre-empting it or causing extra latency when scheduling
it.
This makes sense. But as I asked, why doesn't the OS implement some
communications between the IO thread and the VM Pager, so that when a
lot of VM page faulting occurs that the IO thread does not starve?
Unless, of course, the page faulting is in the IO thread.
Shark will show you in excruciating detail when this happens, as
will latency traces.
Can you please give me the settings or a configuration file for shark
so that it exhibits this information?
The problem is that this happens more frequently when plug-in
samplers are running. This makes it hard for the host to debug. These
samplers may be doing heavy disk i/o at times to load samples or
perhaps their sample buffers are not wired in memory and page faults
occur.
It just does not make sense to me that we should get an audio glitch
because a page in another thread/process is not loaded in memory! The
OS should compensate for this.
Also note that when you debug an app with gdb, you are stopping all
the threads in the app every time you hit a break point or otherwise
cause gdb to halt the app. Consequently, you can expect to see many
more overloads than usual.
On Feb 14, 2005, at 6:40 PM, Jeremy Sagan wrote:
Jeff,
I am not too familiar with the OS so I could be way off here but I
also have some questions regarding glitches. I do get overload
notifications though and they seem to happen way more if GDB is
running.
Is it possible to get a glitch solely because of VM from a
different thread? If another thread is taking a lot of page faults
all in a row would that cause the I/O procedure to be starved? If
the answer to the first two is yes, then shouldn't there be a
mechanism in the OS that causes the audio I/O procedures to get
called immediately after the first and between each page fault?
Jeremy
On Feb 14, 2005, at 6:46 PM, Jeff Moore wrote:
Glitches that don't correspond to over loads can be caused by lots
of things. The usual cause is supply chain issues, but there have
been a handful that are hardware/driver related.
--
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