On Thu, 10 Aug 2000, Ethan Solomita wrote:

> 	Here's the problem I'm trying to overcome: a user profile today works
> by having statclock() be called periodically from clock interrupt, and
> if the frame's PC is in user land, then it increments the appropriate
> bucket in the user's profile counts. In the event that the user process
> made a system call, and the clock interrupt comes in during the system
> call, or if the clock interrupt interrupts some other interrupt, the
> frame that gets passed to statclock() contains the kernel's PC, and thus
> no profiling information is computed.

Hm.  Arguably it would make sense to reimplement this using cycle counters
where possible rather than sampling.

> 	This has a major limitation, in that all system calls appear to take
> zero time. For cpu-bound apps this isn't so bad, however it's nearly
> useless for I/O-bound apps.	I want the kernel to do two extra things:
> 
> 1. In statclock(), if the frame's PC points into kernel space, extract
> the user's last PC before entering the kernel and increment the bucket
> for that PC.
> 
> 2. Count time spent sleeping, waiting to be woken up, against the user's
> last PC before entering the kernel and increment for the full time spent
> sleeping.

Why do you want to count time spent sleeping waiting for an event against
the process?

> 	The first item above solves the problem of "sys time", ie. time spent
> actively running in the kernel. The second item solves the problems of
> the process sleeping, eg. waiting for I/O to complete. If the app calls
> read(), I want the user profile to report the read() routine in libc as
> taking up all the time until the read completes.

Who do you charge the time spent servicing interrupts to?  They may be
completely unrelated to any particular process.

Eduardo Horvath