[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