Updated rusage patch

[Jeff Roberson]

On Tue, 5 Jun 2007, Bruce Evans wrote:

> On Tue, 5 Jun 2007, Attilio Rao wrote:
>
>> Yes, I always wondered why proc0_post() doesn't initialize [s,i,u]ticks 
>> too.
>> However, could you please give a look and a try to this patch:
>> http://users.gufi.org/~rookie/works/patches/schedlock/proc_post.diff
>> 
>> and see if it solves your problem.
>
> This can probably be fixed more simply by calling rufetch() to reset the
> time state in threads as a side effect.  Do this before resetting the
> state in the process.

Ok, I agree with bde here, just call rufetch and this will clear each 
thread, and then you can clear the rux in the proc.

I'd like to make a list of the remaining problems with rusage and 
potential fixes.  Then we can decide which ones myself and attilio will 
resolve immediately to clean up some of the effect of the sched lock 
changes.

1)  The ruadd() in thread_exit() is not safe since we're accessing another 
thread's unlocked rusage structure.  Potential solution is to allocate 
p_ru as part of the proc struct and add into there, which will be 
protected by the PROC_SLOCK, which bde seemed to like better anyway.

2)  We may lose information between exit1() and thread_exit() due to the 
way p_ru is initialized before we're done exiting.  There also seems to be 
a race where wait() operates on a process before it's done in 
thread_exit() which means wait may return rusage information without the 
child added in!  The solution will be to fix this race, and then access 
p_ru directly in wait().

3)  There is no locking around rufetch() and calcru().  calcru() may apply 
new rux values to an old rusage, giving inaccurate results.  The solution 
is to either require the proc slock around both calls, or provide a new 
routine which does the fetch and calc while grabbing the lock itself.

4)  libkvm has had the rusage support if'd out because I broke it when I 
removed pstats.p_ru.  Do we care about rusage in libkvm?  Should we go to 
the trouble of traversing the list of threads and sum'ing it up?  Can we 
export some subset of the information?  Does anyone use this (other than 
bde ;).

Jeff

>
> ANother minor problem is that proc0_post() isn't the right place to
> reset the time state except for proc0.  It hacks on some of the time
> state for all processes and thus for all CPUs, but only resets switchtime
> and switchticks for the current CPU.  Resetting of switchtime and
> switchticks for startup of other CPUs now seems to be in sched_throw().
> I think this is not properly synchronous with the resetting of the
> rest of the state, but the errors from this are tiny.
>
> Bruce
>