linux-kernel - Re: Dynamic ticks make system jerking

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]

Message-Id: <1182872749.11854.27.camel@chaos>
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/