Date: Wed, 30 May 2007 16:36:05 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. Message-ID: <20070530161912.P12540@besplex.bde.org> In-Reply-To: <20070529201255.X661@10.0.0.1> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1> <20070530065423.H93410@delplex.bde.org> <20070529141342.D661@10.0.0.1> <20070530125553.G12128@besplex.bde.org> <20070529201255.X661@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 May 2007, Jeff Roberson wrote: > On Wed, 30 May 2007, Bruce Evans wrote: > >> On Tue, 29 May 2007, Jeff Roberson wrote: >>> 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. >> >> This became clearer with patches and would have been clearer with >> (smaller) diffs in mail -- mi_switch() still needs locking but it isn't >> sched locking. > > Hopefully you see the value in my approach now? I don't think it's turning > out so badly, except for some details which need refining. It certainly make > mi_switch() and statclock() cleaner. And hopefully we can remove more code > from ast() and mi_switch() by changing the cpu limits. Yes, it shows promise. I like the possibility of fixing the stats for other CPUs in calcru() in a general way. The aggregation points also give a good place to fix the scaling by the cputick frequency. The cputick frequency may be variable, so the current frequency should not be used to scale all previously recorded ticks. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070530161912.P12540>