Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933712AbdC3M56 (ORCPT ); Thu, 30 Mar 2017 08:57:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57832 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933173AbdC3M55 (ORCPT ); Thu, 30 Mar 2017 08:57:57 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BC1793DBD4 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BC1793DBD4 Message-ID: <1490878672.28917.13.camel@redhat.com> Subject: Re: [BUG nohz]: wrong user and system time accounting From: Rik van Riel To: Frederic Weisbecker Cc: Luiz Capitulino , Wanpeng Li , linux-kernel@vger.kernel.org, Thomas Gleixner Date: Thu, 30 Mar 2017 08:57:52 -0400 In-Reply-To: <20170329225428.GC23895@lerouge> References: <20170323165512.60945ac6@redhat.com> <1490636129.8850.76.camel@redhat.com> <20170328132406.7d23579c@redhat.com> <20170329131656.1d6cb743@redhat.com> <1490818125.28917.11.camel@redhat.com> <20170329225428.GC23895@lerouge> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 30 Mar 2017 12:57:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1057 Lines: 32 On Thu, 2017-03-30 at 00:54 +0200, Frederic Weisbecker wrote: > (Adding Thomas in Cc) > > On Wed, Mar 29, 2017 at 04:08:45PM -0400, Rik van Riel wrote: > >  > > Frederic, can you think of any reason why > > the tick on nohz_full CPUs would end up aligned > > with the tick on cpu0, instead of running at some > > random offset? > > tick_init_jiffy_update() takes that decision to align all ticks. > > I'm not sure why.  I don't see why that would matter, either. > I'm not sure that randomizing the tick start per CPU would be a > right solution. Somewhere in the world you can be sure the tick > randomization of some nohz_full CPU will coincide with the tick > of CPU 0 :o) > > Or we could force that tick on nohz_full CPUs to be far from > CPU 0's tick... I'm not sure such a solution would be accepted > though. I am not sure we would have to force things. Simply getting rid of tick_init_jiffy_update and scheduling the next tick for "now + tick period" might have the same effect, when the tick gets stopped and restarted on nohz_full CPUs.