[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170425134448.hmhsnq2nnlz6jbci@hirez.programming.kicks-ass.net>
Date: Tue, 25 Apr 2017 15:44:48 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Lofstedt, Marta" <marta.lofstedt@...el.com>
Cc: "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...nel.org" <mingo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ville.syrjala@...ux.intel.com" <ville.syrjala@...ux.intel.com>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"martin.peres@...ux.intel.com" <martin.peres@...ux.intel.com>,
"pasha.tatashin@...cle.com" <pasha.tatashin@...cle.com>,
"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>
Subject: Re: [PATCH 0/9] sched_clock fixes
On Tue, Apr 25, 2017 at 09:31:40AM +0000, Lofstedt, Marta wrote:
> Hi Peterz,
>
> I tested your patch-set on the same Core2 machine as where we discovered the regression.
> With the tsc=unstable boot param that passrate has improved significantly; 350 fails -> 15 fails.
So is that the same as before, or still worse? I don't really have a
handle on what your benchmark is here, nor what how 'good' is defined.
If its still worse than before, I'm completely confused. Because with
"tsc=unstable" the patch you fingered is a complete no-op (__gtod_offset
== 0).
Powered by blists - more mailing lists