initial rusage patch.

[Jeff Roberson]

On Tue, 29 May 2007, Jeff Roberson wrote:

> http://people.freebsd.org/~jeff/rusage3.diff
>
> I'm providing this patch for discussion only.  I've just implemented enough 
> that you can see the fallout from this change.  I have not yet tested enough 
> to say that this is perfect.  I have also not yet fixed the RLIMIT_CPU check 
> in mi_switch().

I have updated the patch at the same location to solve various exit 
related races.  This patch appears to work in the common case.  I have 
only to fix the cpu limit code.  I see three potential ways to do this:

1)  Make a thread that runs once per second and scans all procs looking 
for exceeded cpu limits.

2)  Improve on 1 by making a queue of procs with limits set.

3)  Improve on 2 by setting a per-process timeout.

The only disadvantage to 2 and 3 is that they require extra space in the 
proc but reduce runtime, especially on systems with no limits.  I advocate 
3 and will start on it later unless anyone makes a strong suggestion 
otherwise.  Actually, it seems that if I use a callout_handle the storage 
overhead in the proc is only one pointer.  So this definitely seems like 
the way to go.

Jeff

>
> You can see, however, that with this change there is no access to struct proc 
> in mi_switch() except for INVARIANTS and KTR.  Aside, of course, for the 
> rlimit that needs to move anyway.
>
> You can also see, that most access to rusage are done through fewer indirects 
> and to local memory.  The storage impact of struct proc doesn't change as 
> pstat can be reclaimed as it could before.
>
> Furthermore, the only time we need locks is in rufetch() where we aggregate 
> the threads counters and rusage structs into one allocated by the caller. 
> Doing this aggregation less frequently means we're touching struct proc less 
> frequently.
>
> In this patch the scheduler lock protects this aggregation.  In my threadlock 
> diff this will be protected by the per process spinlock and the thread lock. 
> However, in most places that we aggregate with calcru() we're grabbing a 
> spinlock anyway.  So it is not so expensive to grab another.
>
> Thanks,
> Jeff
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>