Hello, Uwe Kleine-König wrote: > > it's nohz=off not no_hz=off > Currently I'm not sure, which I was really using. I think it was the > right one, because dmesg changed. But anyhow, I will retest if I made > it wrong. OK, I was really using no_hz, and with nohz I got approx the same result as with CONFIG_NO_HZ=n. Uups.
> > > First I wondered why set_next_event is called twice between two timer > > > interrupts most of the time. I found out that the timer is programed > > > for the next tick in any case and if nothing needs the next tick, the > > > interval is enlarged. I didn't spend time yet to check if it is > > > easier/faster to only program the timer once. > > > > We optimize for the non-idle path, i.e. we keep the timer running as > > long as we are not idle. Once we go idle we reprogram it. > OK, sounds sane. Probably you understand that better, but your argument only convinced me for a short time. Is it really better to program at least once and in the idle case a 2nd time instead of only once every time. Moreover if you program the timer late you can notice if the time to tick is already over because the timer irq handling took to long (or CONFIG_HZ is too large). > > I looked at the patch and as far as I can understand it, there is > > nothing obviously wrong about it. > What a pity. I found the problem, it had only indirectly to do with nohz. I didn't acknowledge the serial interrupt but as the timer and the serial need the same acknowledgement the serial irq got his ack always when the timer triggerd. Up to now that delay didn't stick out as the delay was < 10ms. > > One remark: why did you expand the clocksource to be 64 bit? The generic > > code handles the 32 bit wrap already, so the expansion in your read > > routine is adding overhead. The counter will wrap every 24 seconds, so > > there is nothing to worry about. > OK, I thought it to be better to have 64bit + some overhead. I will > change that. done. (But I reserve the right to evaluate the 64bit case and check how worse the overhead is :-) Best regards Uwe -- Uwe Kleine-König http://www.google.com/search?q=sin%28pi%2F2%29 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
