Date: Mon, 10 Apr 2017 17:45:56 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Wanpeng Li <kernellwp@gmail.com>
cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Wanpeng Li <wanpeng.li@hotmail.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Rik van Riel <riel@redhat.com>, Mike Galbraith <efault@gmx.de>,
        Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [PATCH] tick/nohz: Fix wrong user and system time accouting
 against vtime sampling
In-Reply-To: <1491460584-4908-1-git-send-email-wanpeng.li@hotmail.com>
Message-ID: <alpine.DEB.2.20.1704101738240.2906@nanos>
References: <1491460584-4908-1-git-send-email-wanpeng.li@hotmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 695
Lines: 22

On Wed, 5 Apr 2017, Wanpeng Li wrote:
> +	/*
> +	 * Offset the tick to avert jiffies_lock contention, and all ticks
> +	 * alignment in order that the vtime sampling does not end up "in
> +	 * phase" with the jiffies incrementing.
> +	 */
> +	if (sched_skew_tick || tick_nohz_full_enabled()) {
>  		u64 offset = ktime_to_ns(tick_period) >> 1;
>  		do_div(offset, num_possible_cpus());
>  		offset *= smp_processor_id();

That's not a fix, that's just papering over the problem.

       offset = 1ms / 2 = 500us = 500000ns;
       offset /= 144 = 3472ns

So CPU0 and CPU1 ticks are ~3 microseconds apart. That merily reduces the
probability of the issue, but does not prevent it.

Thanks,

	tglx