From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934038AbeAXPGD (ORCPT ); Wed, 24 Jan 2018 10:06:03 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:44868 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933948AbeAXPGC (ORCPT ); Wed, 24 Jan 2018 10:06:02 -0500 Date: Wed, 24 Jan 2018 10:05:58 -0500 (EST) Message-Id: <20180124.100558.97132829347179555.davem@davemloft.net> To: pabeni@redhat.com Cc: torvalds@linux-foundation.org, frederic@kernel.org, linux-kernel@vger.kernel.org, alexander.levin@verizon.com, peterz@infradead.org, mchehab@s-opensource.com, hannes@stressinduktion.org, paulmck@linux.vnet.ibm.com, wanpeng.li@hotmail.com, dima@arista.com, tglx@linutronix.de, akpm@linux-foundation.org, rrendec@arista.com, mingo@kernel.org, sgruszka@redhat.com, riel@redhat.com, edumazet@google.com, nks.gnu@gmail.com Subject: Re: [RFC PATCH 0/4] softirq: Per vector threading v3 From: David Miller In-Reply-To: <1516805645.2476.23.camel@redhat.com> References: <1516726652.2554.58.camel@redhat.com> <1516805645.2476.23.camel@redhat.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Paolo Abeni Date: Wed, 24 Jan 2018 15:54:05 +0100 > Niklas suggested a possible relation with CONFIG_IRQ_TIME_ACCOUNTING=y > and indeed he was right. > > The patched kernel under test had CONFIG_IRQ_TIME_ACCOUNTING set, and > very little CPU time was accounted to the kworker: > > [2125 is the relevant kworker's pid] > grep sum_exec_runtime /proc/2125/sched; sleep 10; grep sum_exec_runtime /proc/2125/sched > se.sum_exec_runtime : 13408.239286 > se.sum_exec_runtime : 13456.907197 > > despite such process was processing a lot of packets and basically > burning a CPU. So IRQ_TIME_ACCOUNTING makes the scheduler think that the worker threads are using nearly no task time at all. The existing ksoftirqd code should hit the same problem, right?