lists.openwall.net   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  linux-hardening  linux-cve-announce  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:	Tue, 26 Jun 2007 17:45:49 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Uwe Kleine-König 
	<ukleinek@...ormatik.uni-freiburg.de>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Dynamic ticks make system jerking

On Tue, 2007-06-26 at 17:00 +0200, Uwe Kleine-König wrote:
> If I enable NO_HZ, the system jerks (I hope this is an understandable
> term ...).   E.g. 
> 
> 	# time find /sys
> 	...
> 	real    1m 19.52s
> 	user    0m 0.18s
> 	sys     0m 0.15s
> 
> on a freshly booted machine.  The output comes in several hunks with
> pausing between them.  With no_hz=off, I get approx. the same.

it's nohz=off not no_hz=off

> If I have NO_HZ disabled however, I get
> 
> 	# time find /sys
> 	...
> 	real    0m 1.53s
> 	user    0m 0.15s
> 	sys     0m 0.18s

Well, you run in periodic mode then.

> Another thing is, if I press Enter once, the next prompt appears in a
> reasonable time.  If I press twice in a row the 2nd prompt needs
> perceptible longer.
> 
> Does someone have a hint for me how to debug (or even solve) this problem?
> 
> 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.

I looked at the patch and as far as I can understand it, there is
nothing obviously wrong about it.

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.

The behavior you are describing is might be related to some problem with
the clocksource readout, as the reprogramming values are calculated from
there. 

	tglx




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ