[PATCH] Statclock aliasing by LAPIC
Bruce Evans
brde at optusnet.com.au
Tue Jan 19 19:39:45 UTC 2010
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
More information about the freebsd-arch
mailing list