Re: context switching and profiling
Re: context switching and profiling
- Subject: Re: context switching and profiling
- From: Jim Magee <email@hidden>
- Date: Fri, 21 Jun 2002 13:29:08 -0400
On Friday, June 21, 2002, at 12:50 PM, Jonathan Hess wrote:
How would one receive notification (signal or otherwise) that the
current thread is about to be or was just swapped out and that the
current thread is about to be or was just swapped back in?
By "just about to be swapped out" I assume you mean "just about to lose
control/ownership of a processor." If so, the answer is "no way, no
how." That is about the most time critical path in the system. We
can't put notifications/callbacks in there. I guess if you wanted to
waste your own cycles on processing a "just got control back" kind of
notification, that would be a different thing. But I don't think it
would be very useful, and there is no such mechanism today.
With present compilers and the PPC RTC register "active" profilers are
a real possibility. But, to make them robust on a preemptive
multi-cpu OS the question above must be resolved.
I've thought about instrumenting semaphore and mutex abstractions and
finding and instrumenting the time slice expired signal. To be
generally useful, all calls that would likely block the current thread
(read, write, accept, glFlush, etc, etc) would have to be
instrumented. But these all just seem like problematic hacks that
avoid finding the real solution.
Is there an exposed relatively hi-level way in the shipping kernel to
do this? If not, any pointers on where to look in the kernel?
No real-time notifications. But there is a trace mechanism that gives
you the raw information to post-process. That's the same data that
feeds the sc_usage, fs_usage, and latency performance utility tools.
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.