From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752299AbeAXB5m (ORCPT ); Tue, 23 Jan 2018 20:57:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:40940 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751964AbeAXB5l (ORCPT ); Tue, 23 Jan 2018 20:57:41 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1F3D2178D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=frederic@kernel.org Date: Wed, 24 Jan 2018 02:57:36 +0100 From: Frederic Weisbecker To: David Miller Cc: torvalds@linux-foundation.org, pabeni@redhat.com, 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 Subject: Re: [RFC PATCH 0/4] softirq: Per vector threading v3 Message-ID: <20180124015734.GA11302@lerouge> References: <20180123.112201.1263563609292212852.davem@davemloft.net> <1516726652.2554.58.camel@redhat.com> <20180123.132424.1035340800864767853.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180123.132424.1035340800864767853.davem@davemloft.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 23, 2018 at 01:24:24PM -0500, David Miller wrote: > From: Linus Torvalds > Date: Tue, 23 Jan 2018 09:42:32 -0800 > > > But I wonder if the test triggers the "lets run lots of workqueue > > threads", and then the single-threaded user space just gets blown out > > of the water by many kernel threads. Each thread gets its own "fair" > > amount of CPU, but.. > > If a single cpu's softirq deferral can end up running on multiple > workqueue threads, indeed that's a serious problem. > > So if we're in a workqueue and it does a: > > schedule_work_on(this_cpu, currently_executing_work); > > it'll potentially make a new thread? > > That's exactly the code path that will get exercised during a UDP > flood the way that vector_work_func() is implemented. It shouldn't create a new thread unless all other workers in the CPU are voluntarily sleeping while executing a work. Also since softirqs can't sleep, we shouldn't even have two vectors running concurrently on workqueues.