rusage breakdown and cpu limits.

[John Baldwin]

On Tuesday 29 May 2007 05:18:32 pm Jeff Roberson wrote:
> On Wed, 30 May 2007, Bruce Evans wrote:
> > I see how rusage accumulation can help for everything _except_ the
> > runtime and tick counts (i.e., for stuff updated by statclock()).  For
> > the runtime and tick counts, the possible savings seem to be small and
> > negative.  calcru() would have to run the accumulation code and the
> > accumulation code would have to acquire something like sched_lock to
> > transfer the per-thread data (since the lock for updating that data
> > is something like sched_lock).  This is has the same locking overheads
> > and larger non-locking overheads than accumulating the runtime directly
> > into the rusage at context switch time -- calcru() needs to acquire
> > something like sched_lock either way.
> 
> Yes, it will make calcru() more expensive.  However, this should be 
> infrequent relative to context switches.  It's only used for calls to 
> getrusage(), fill_kinfo_proc(), and certain clock_gettime() calls.
> 
> The thing that will protect mi_switch() is not process global.  I want to 
> keep process global locks out of mi_switch() or we reduce concurrency for 
> multi-threaded applications.

I still think it would be wise to try the simple approach first and only 
engage in further complexity if it is warranted.

-- 
John Baldwin