Date: Tue, 29 May 2007 17:37:24 -0400 From: John Baldwin <jhb@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. Message-ID: <200705291737.25355.jhb@freebsd.org> In-Reply-To: <20070529141342.D661@10.0.0.1> References: <20070529105856.L661@10.0.0.1> <20070530065423.H93410@delplex.bde.org> <20070529141342.D661@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705291737.25355.jhb>