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: <20120417153032.GB21534@burratino>
Date:	Tue, 17 Apr 2012 10:30:32 -0500
From:	Jonathan Nieder <jrnieder@...il.com>
To:	Lesław Kopeć <leslaw.kopec@...za-klasa.pl>
Cc:	Peter Zijlstra <peterz@...radead.org>, Aman Gupta <aman@...1.net>,
	linux-kernel@...r.kernel.org,
	Chase Douglas <chase.douglas@...onical.com>,
	Damien Wyart <damien.wyart@...e.fr>,
	Kyle McMartin <kyle@...hat.com>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Doug Smythies <dsmythies@...us.net>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Inconsistent load average on tickless kernels

Lesław Kopeć wrote:

> I've finally finished testing patch c308b56b53. Apologies for the delay
> in reporting back. This time I've compared kernels from 3.2 and 2.6.32
> branches. Here's a snapshot of load 15 on different versions:
[...]
> Just to make things clear 2.6.32 kernels were patched as follows:
> * 74f5187ac8 - just 74f5187ac8
> * 0f004f5a69 - 74f5187ac8 + 0f004f5a69
> * c308b56b53 - 74f5187ac8 + 0f004f5a69 + c308b56b53
>
> For kernel 3.2.12 patch c308b56b53 seems almost perfect. For low CPU
> utilization the load value is slightly lower for NO_HZ version than it
> is for HZ one. However the difference is small and the overall trend
> relates to CPU usage quite closely.

Nice.

[...]
> Looking at results for 2.6.32.55 branch it seems that we're back at
> 74f5187ac8 patch - the values are almost the same. The difference
> between NO_HZ and HZ versions is noticeable.

How does 3.0.y + c308b56b53 do?  (I ask because the usual flow of
fixes is mainline -> 3.3.y -> 3.2.y -> 3.0.y -> 2.6.32.y with the
first three steps happening pretty quickly, so it we can get this
working on 3.0.y then that would be progress.  Also because, like
2.6.32.y, 3.0.y is longterm maintained, so it might be useful in the
meantime.)

Curious,
Jonathan
--
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