On Thu, 2 Aug 2001, george anzinger wrote:
> Ok, but then what? The head timer expires. Now what? Since we are not
> clocking the slice we don't know when it started. Seems to me we are
> just shifting the overhead to a different place and adding additional
> tests and code to do it. The add_timer() code is fast. The timing
> tests (800MHZ PIII) show the whole setup taking an average of about 1.16
> micro seconds. the problem is that this happens, under kernel compile,
> ~300 times per second, so the numbers add up.
As you said, most of those 'time to reschedule' timers never expire - we
hit a rescheduling point first, yes? In the old system, we essentially had
one 'time to reschedule' timer pending at any given time, I'm just trying
to approximate that.
> Note that the ticked
> system timer overhead (interrupts, time keeping, timers, the works) is
> about 0.12% of the available cpu. Under heavy load this raises to about
> 0.24% according to my measurments. The tick less system overhead under
> the same kernel compile load is about 0.12%. No load is about 0.012%,
> but heavy load can take it to 12% or more, most of this comming from the
> accounting overhead in schedule(). Is it worth it?
Does the higher timer granularity cause overall throughput to improve, by
any chance?
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:23 EST