Received: by 10.223.176.46 with SMTP id f43csp160877wra; Tue, 23 Jan 2018 18:14:20 -0800 (PST) X-Google-Smtp-Source: AH8x2241hDRSx9lRqEIJlvHwZV1VbYXc6Qshz4cFUdb4u4fi6XMnrmaBij0IZjEL5ssbG4SEnDgt X-Received: by 10.98.220.195 with SMTP id c64mr11410930pfl.47.1516760060662; Tue, 23 Jan 2018 18:14:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516760060; cv=none; d=google.com; s=arc-20160816; b=ksSZZF3t3fqiOpaRouY48jJKtzlUgEYX4EQiRXjfwEWF0hVCdWvTjGbXbSpQd/+imK BlgKPuwKsMKRvq4jxdygpFN+sOhDOiWNX+PjKe+/6MCm12/lzzKftsbLiz5Do/XgJh81 4XMN3FP14wDD9qHqu3xIWg0KPUWt4nTlA6GEw0Q//z6mhCsKrFz/rzqhJQ/k3okOw4Dq fqTazUiHKPvpbZp25FS4lTOoy9VihP/pTScg/ubghvj0qQmBBSrSz/xa1zHZETumECVp WbPzVT3I5UO4SJ9dJI+bjAvNQpTyFtVH2VDoNiuuEi6rc4QhFaRkMvTF+26HaOjK5+Zf NBUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:arc-authentication-results; bh=lCM51X7og3vevLQOoyA/6q04xygxBOx3rKZx66SXwTM=; b=uAsWxN3oMD6Hq4jCFq3KLEu3XUSjrT9esA75KzFqYKyR9vV1xtCGhzNEz1lj9cXwot kG+731idaF+jG2ms/bwSqbFBAzD8nks/ZbfQbbJ35xBk6Qs+GcES3P6i/SwsfiMmP4Hg TwzyAVIZvSyaYmekH6sOFbqhtEl2rGh3PG0oTkPNGlVRedLQyeQrMHj8tG+coy2aKoAm p6yxbRXJo8/fHkWdyPccLnufpnNJOG3+z5JauZ/8ZqNiqzrdDVvvGdBaW6+6RcsT66IR nb+GQRofPIsS1h8+wRKY5vf5tsFPjsbHm2SDe38928d4iYGvSPEKzhzcZdL6vizw38Vk 12gg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g21-v6si5378066plo.236.2018.01.23.18.14.06; Tue, 23 Jan 2018 18:14:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752399AbeAXCMF (ORCPT + 99 others); Tue, 23 Jan 2018 21:12:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:45476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752148AbeAXCME (ORCPT ); Tue, 23 Jan 2018 21:12:04 -0500 Received: from localhost (i16-les03-th2-31-37-47-191.sfr.lns.abo.bbox.fr [31.37.47.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F1280217AB; Wed, 24 Jan 2018 02:12:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1280217AB 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 03:12:01 +0100 From: Frederic Weisbecker To: Dmitry Safonov Cc: Paolo Abeni , LKML , Levin Alexander , Peter Zijlstra , Mauro Carvalho Chehab , Linus Torvalds , Hannes Frederic Sowa , "Paul E . McKenney" , Wanpeng Li , Thomas Gleixner , Andrew Morton , Radu Rendec , Ingo Molnar , Stanislaw Gruszka , Rik van Riel , Eric Dumazet , David Miller Subject: Re: [RFC PATCH 0/4] softirq: Per vector threading v3 Message-ID: <20180124021159.GB11302@lerouge> References: <1516376774-24076-1-git-send-email-frederic@kernel.org> <1516702432.2554.37.camel@redhat.com> <1516710733.2762.19.camel@arista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516710733.2762.19.camel@arista.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 23, 2018 at 12:32:13PM +0000, Dmitry Safonov wrote: > On Tue, 2018-01-23 at 11:13 +0100, Paolo Abeni wrote: > > Hi, > > > > On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote: > > > As per Linus suggestion, this take doesn't limit the number of > > > occurences > > > per jiffy anymore but instead defers a vector to workqueues as soon > > > as > > > it gets re-enqueued on IRQ tail. > > > > > > No tunable here, so testing should be easier. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux- > > > dynticks.git > > > softirq/thread-v3 > > > > > > HEAD: 6835e92cbd70ef4a056987d2e1ed383b294429d4 > > > > I tested this series in the UDP flood scenario, binding the user > > space > > process receiving the packets on the same CPU processing the related > > IRQ, and the tput sinks nearly to 0, like before Eric's patch. > > > > The perf tool says that almost all the softirq processing is done > > inside the workqueue, but the user space process is scheduled very > > rarely, while before this series, in this scenario, ksoftirqd and the > > user space process got a fair share of the CPU time. > > It get a fair share of the CPU time only on some lucky platforms (maybe > on the most). On other not-so-lucky platforms it was also unfair - as > I've previously described by the reason of slow raising softirqs :-/ Indeed your case looks pretty special, as IRQs don't get the opportunity to interrupt softirqs but they fire right after. I'm wondering if you shouldn't try threaded IRQs. Having softirqs always running in a thread instead of hardirq tail might help (through threadirqs= kernel param).