Date: Wed, 20 Jan 2010 06:39:41 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, FreeBSD Arch <arch@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Statclock aliasing by LAPIC Message-ID: <20100120062222.N68139@delplex.bde.org> In-Reply-To: <201001191413.03682.jhb@freebsd.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <201001191144.23299.jhb@freebsd.org> <20100120042822.L4223@besplex.bde.org> <201001191413.03682.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Jan 2010, John Baldwin wrote: > On Tuesday 19 January 2010 1:53:32 pm Bruce Evans wrote: >> On Tue, 19 Jan 2010, John Baldwin wrote: >>> My feeling, btw, is that the real solution is to not use a sampling clock for >>> per-process stats, but to just use the cycle counter and keep separate user, >>> system, and interrupt cycle counts (like the rux_runtime we have now). >> >> The total runtime info is already available (in rux_runtime). It is >> the main thing that we use to see that scheduling is broken :-) -- we >> see that the runtime is too large or small relative to %CPU. I think >> using this and never using ticks for scheduling would work OK. Schedulers >> shouldn't care about the difference between user and sys time. Something >> like this is also needed for tickless kernels. > > I mostly care about splitting up the timers to attempt to remove the need > for statclock() by making more stats event-driven rather than sampled (to > help with a tickless kernel). vm stats are inherently sampled at points not related to vm events, but could probably be sampled on other interrupts. > I also would like to simplify calcru() and > remove the weird hacks to satisfy monoticity (sp?). I don't know of any hacks in calcru(). Did someone break it? :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100120062222.N68139>