> > It might be nice for our idle process to burn idle cycles and compute
> > nuber of cycles burned. This would give pretty accurate numbers.
> >
> > PS: I've done that. There is only one problem: it is _bad_ idea on
> > notebook computer. It may be even bad idea on desktop because more
> > power consumed means more heat and marginal hw will fail. (Not
> > counting adverse effects on environment...)
>
> There's probably a way to do the same thing without having the idle
> process spin. E.g., read time on entering interrupt, read time on
Well, read time on entering interrupt is the hard part, I
believe. It is probably inacceptable to increase interrupt latency
just for some statistics...
> returning to idle process. (Will be fast when TSC contents are valid,
> we don't mind the timer chip latency when it isn't).
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/