Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932484AbdC1NT0 (ORCPT ); Tue, 28 Mar 2017 09:19:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38292 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932388AbdC1NTW (ORCPT ); Tue, 28 Mar 2017 09:19:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 40034C04BD3B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=brouer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 40034C04BD3B Date: Tue, 28 Mar 2017 15:18:54 +0200 From: Jesper Dangaard Brouer To: Frederic Weisbecker Cc: Peter Zijlstra , Wanpeng Li , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , linux-mm , Mel Gorman , Tariq Toukan , Tariq Toukan , Rik van Riel , Thomas Gleixner , Ingo Molnar , brouer@redhat.com Subject: Re: Bisected softirq accounting issue in v4.11-rc1~170^2~28 Message-ID: <20170328151854.5c50dbd4@redhat.com> In-Reply-To: <20170328130602.GA4216@lerouge> References: <20170328101403.34a82fbf@redhat.com> <20170328122642.dhw2zkjbghfw4fzn@hirez.programming.kicks-ass.net> <20170328130602.GA4216@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 28 Mar 2017 13:19:02 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1105 Lines: 28 On Tue, 28 Mar 2017 15:06:04 +0200 Frederic Weisbecker wrote: > On Tue, Mar 28, 2017 at 02:26:42PM +0200, Peter Zijlstra wrote: > > On Tue, Mar 28, 2017 at 06:34:52PM +0800, Wanpeng Li wrote: > > > > > > sched_clock_cpu(cpu) should be converted from cputime to ns. > > > > Uhm, no. sched_clock_cpu() returns u64 in ns. > > Yes, and most of the cputime_t have been converted to u64 so there > should be no such conversion issue between u64 and cputime_t anymore. > > Perhaps my commit has another side effect on softirq time accounting, > I'll see if I can reproduce. (Disclaimer without knowing anything about the scheduler code) my theory is that irqtime_account_irq() does not get invoked often enough, as in my pktgen "overload" use-case keeps softirq always running. And your change moved updating cpustat[CPUTIME_SOFTIRQ] here. Before it got updated by account_other_time() which gets invoked from irqtime_account_process_tick(). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer