From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753428AbcGYQfg (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Jul 2016 12:35:36 -0400
Received: from resqmta-ch2-05v.sys.comcast.net ([69.252.207.37]:57142 "EHLO
	resqmta-ch2-05v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1753071AbcGYQfe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Jul 2016 12:35:34 -0400
Date: Mon, 25 Jul 2016 11:35:30 -0500 (CDT)
From: Christoph Lameter <cl@linux.com>
X-X-Sender: cl@east.gentwo.org
To: Chris Metcalf <cmetcalf@mellanox.com>
cc: Gilad Ben Yossef <giladb@mellanox.com>,
        Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Rik van Riel <riel@redhat.com>, Tejun Heo <tj@kernel.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        Andy Lutomirski <luto@amacapital.net>,
        Daniel Lezcano <daniel.lezcano@linaro.org>, linux-doc@vger.kernel.org,
        linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v13 00/12] support "task_isolation" mode
In-Reply-To: <7a3f66f7-5011-7d59-2e0e-f57e4e42e6b6@mellanox.com>
Message-ID: <alpine.DEB.2.20.1607251133450.25354@east.gentwo.org>
References: <1468529299-27929-1-git-send-email-cmetcalf@mellanox.com> <alpine.DEB.2.20.1607202059180.25838@east.gentwo.org> <e60d7fd1-022d-c823-52e6-d44a49d274b1@mellanox.com> <alpine.DEB.2.20.1607212118210.12213@east.gentwo.org>
 <7a3f66f7-5011-7d59-2e0e-f57e4e42e6b6@mellanox.com>
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfKeGM1SwGgp6149xz/Q7mafoinP9z/o921nVFSu/LrAX6E6IdYTC48VM24maSRf7XwAEoB1JrizXxb4mSuHx9/PaX8JUgFLuNIPz7kIyMpu4D5elKc+f
 r4fsEQIADLd21UgFxRzlQ9Jo3cDI5gPb/K6gGPyzS+ICqqnthonHcAXjA8Qx7tW2WkSGcIQ6z6auRhjZWADfJJ191NUoJSMonGI7wPqv51Hk2V9RH0F7OZFP
 +3Mhk18OTa/INy+Uucb7stWOo6p5a5GNhtxHlDs55Inlfna02NgXeUr0EGFG6vbIro7KodL9oxDEriIHNccFxczWF0O5kLyKnGhY37W9eUvUBwihnA6HFxs0
 fKO/fJErpV64kuNn56Z8ZCdQLOookJRHQ1yDx50GUEZMohbMz/wvdza8d+bESi2Jc6nSPL/vewHtjmKaeWtO+7AJmlblu7ZGHgtEB5w6gEgaGZ0FPayuGHxX
 qVE8uHPy65DERNiyJ9lpSCYCgfbUeUyZoBhJUMODKxsYY9Pm3qmhq1aJLB4ftO1RGqV5tUdLiOsejQC/TZZ55euafhY/m2ewF6a3dYujraujkCdpJyTA8JhW
 ZUu4Cxr6p2A86ke1jadFewJV5RF8wiyJ8TWUnUX2Ck9GPzBczAj/ky2xL4bMIX/7aa0seaM4DPMUrh2IfPJTeI+Iqo7TeE2FLLNYs0KqBH/6AN2yUOnZSsxa
 i9gJTczO5ng/ATeJmb8RmV7sQW+QyiZrqYI/RxV6bwGP+nuzc9lAEQ==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 22 Jul 2016, Chris Metcalf wrote:

> > It already as a stable clocksource. Sorry but that was one of the criteria
> > for the server when we ordered them. Could this be clock adjustments?
>
> We probably need to get clock folks to jump in on this thread!

Guess so. I will have a look at this when I get some time again.

> Maybe it's disabling some built-in unstable clock just as part of
> falling back to using the better, stable clock that you also have?
> So maybe there's a way of just disabling that clocksource from the
> get-go instead of having it be marked unstable later.

This is a standard Dell server. No clocksources are marked as unstable as
far as I can tell.

> If you run the test again after this storm of unstable marking, does
> it all happen again?  Or is it a persistent state in the kernel?

This happens anytime we try to run with prctl().

I hope to get some more detail once I get some time to look at this. But
this is likely an x86 specific problem.