Re: rusage breakdown and cpu limits.

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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"