linux-kernel - Re: [PATCH] [RFC] timekeeping: Rework frequency adjustments to work better w/ nohz

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: <20140113175114.GA4271@netboy>
Date:	Mon, 13 Jan 2014 18:51:16 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Miroslav Lichvar <mlichvar@...hat.com>,
	Prarit Bhargava <prarit@...hat.com>
Subject: Re: [PATCH] [RFC] timekeeping: Rework frequency adjustments to work
 better w/ nohz

On Mon, Jan 06, 2014 at 07:57:03PM -0800, John Stultz wrote:
> 
> I still think this is probably 3.15 or later material, but I'd be
> very interested in feedback, thoughts, and testing.

Over the weekend I did a short test of this new approach. I compiled
two kernels, one plain v3.12.7 and one with the proposed fix. The
test was run on three different kernel variants, the current nohz
kernel, the same with nohz=off, and the same but with John's patch.

I used a simple test script (see below). Using a PCIe express card as
a PHC, the Intel Corporation 82574L, I simply let the this clock run
free (not sync'ed to gps or anything), and then synchronized the Linux
system clock to the PHC using the phc2sys program with a sample rate
of once every 32 seconds. Each of the tests ran for at least three
hours on a system without any other load.

- Linux 3.12.7-nohz-plain-20140106                nohz-plain.log
- Linux 3.12.7-nohz-plain-20140106 NOHZ=OFF       periodic-plain.log
- Linux 3.12.7-nohz-fix-20140106-00001-gd753140   nohz-fix.log

The performance in the log files as reflected in the clock offset is
summarized in this table. The values are in nanoseconds.

 |         | periodic-plain |      nohz-fix |    nohz-plain |
 |---------+----------------+---------------+---------------|
 | minimum |  -1.599000e+03 | -1.051000e+03 | -5.373700e+04 |
 | maximum |  +1.311000e+03 | +1.048000e+03 | +6.389500e+04 |
 | mean    |  +9.880240e-02 | -7.747305e+01 | +1.597904e+01 |
 | stddev  |  +4.610021e+02 | +3.960978e+02 | +1.491263e+04 |

I also made two graphs.

   http://linuxptp.sourceforge.net/nohz-fix/current_nohz.png
   http://linuxptp.sourceforge.net/nohz-fix/periodic_vs_fix.png

(The log files and scripts are also in that directory.)

So in this test, it looks like the new approach performed at least as
well as using regular, periodic ticks.

Thanks,
Richard

---
# nohz-fix-testing.sh
#
# set the ptp clock time from the system time
#
./testptp -s; ./testptp -g; date
#
# wait a bit to let the clocks drift
#
sleep 10
#
# start the servo
#
./phc2sys -s eth4 -m -q -l7 -O0 -P0 -I0 -R.03125
--
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/