lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 30 Jun 2007 00:33:03 +0200
From:	Uwe Kleine-König 
To:	Thomas Gleixner <>
Cc:, Ingo Molnar <>
Subject: Re: Dynamic ticks make system jerking


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 Kleine-König
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists