From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933790AbdC3NCh (ORCPT ); Thu, 30 Mar 2017 09:02:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62752 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933107AbdC3NCg (ORCPT ); Thu, 30 Mar 2017 09:02:36 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 886BC8EB58 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 886BC8EB58 Message-ID: <1490878951.28917.16.camel@redhat.com> Subject: Re: [BUG nohz]: wrong user and system time accounting From: Rik van Riel To: Frederic Weisbecker , Mike Galbraith Cc: Luiz Capitulino , Wanpeng Li , linux-kernel@vger.kernel.org Date: Thu, 30 Mar 2017 09:02:31 -0400 In-Reply-To: <20170330125157.GB3626@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> <1490848051.4167.57.camel@gmx.de> <20170330125157.GB3626@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.26]); Thu, 30 Mar 2017 13:02:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-03-30 at 14:51 +0200, Frederic Weisbecker wrote: > On Thu, Mar 30, 2017 at 06:27:31AM +0200, Mike Galbraith wrote: > > On Wed, 2017-03-29 at 16:08 -0400, Rik van Riel wrote: > > > > > A random offset, or better yet a somewhat randomized > > > tick length to make sure that simultaneous ticks are > > > fairly rare and the vtime sampling does not end up > > > "in phase" with the jiffies incrementing, could make > > > the accounting work right again. > > > > That improves jitter, especially on big boxen.  I have an 8 socket > > box > > that thinks it's an extra large PC, there, collision avoidance > > matters > > hugely.  I couldn't reproduce bean counting woes, no idea if > > collision > > avoidance will help that. > > Out of curiosity, where is the main contention between ticks? I > indeed > know some locks that can be taken on special cases, such as posix cpu > timers. > > Also, why does it raise power consumption issues? On a system without either nohz_full or nohz idle mode, skewed ticks result in CPU cores waking up at different times, and keeping an idle system consuming power for more time than it would if all the ticks happened simultaneously. This is not a factor at all on systems that switch off the tick while idle, since the CPU will be busy anyway while the tick is enabled.