From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753951AbeAREJ3 (ORCPT ); Wed, 17 Jan 2018 23:09:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:39510 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbeAREJ2 (ORCPT ); Wed, 17 Jan 2018 23:09:28 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FE6720C48 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: Thu, 18 Jan 2018 05:09:24 +0100 From: Frederic Weisbecker To: Linus Torvalds Cc: Mauro Carvalho Chehab , LKML , Levin Alexander , Peter Zijlstra , Hannes Frederic Sowa , "Paul E . McKenney" , Wanpeng Li , Dmitry Safonov , Thomas Gleixner , Eric Dumazet , Radu Rendec , Ingo Molnar , Stanislaw Gruszka , Paolo Abeni , Rik van Riel , Andrew Morton , David Miller Subject: Re: [RFC PATCH 0/5] softirq: Per vector threading v2 Message-ID: <20180118040916.GA25885@lerouge> References: <1516077640-19718-1-git-send-email-frederic@kernel.org> <20180117145620.213cb5ad@vento.lan> <20180117180713.GA17735@lerouge> <20180118025539.GA20310@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jan 17, 2018 at 07:09:39PM -0800, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 6:55 PM, Frederic Weisbecker > wrote: > >> I thought you were going to actally account for time, but I don't > >> think you ended up doing that. > > > > I did in the first version but then I thought you suggested that count per > > jiffy. I probably misunderstood :) > > Oh, miscommunication. > > I tried to suggest to do things purely by time (from an accounting > standpoint), but then to also have some "minimum time" for each > invocation, so that there effectively ends up being an invocation > limit too. Ah ok I see. > > Honestly, that's mainly because I worry about just how good the > time-based approach might be (ie some hardware doesn't have a good > high-frequency clock to read etc. > > On x86-64, the TSC would be fairly natural as a clock, but we support > architectures without anything like that, so time-based definitely has > some issues. Yeah indeed, there is that too. Performance and reliability. > > But thinking about it more, I do end up liking my suggested "just keep > a bitmap of softirqs that have been handled" thing, and kick the > softirq to a thread if it ever seems to get into that "we already saw > this one". > > It might just work very naturally, and it sure as hell is simple and > has no subtle interactions with the granularity of whatever random > clock the architecture or platform has. > > It should never trigger under any normal load, but I think it *should* > trigger under the load that the networking people worry about. If you > get a flood of UDP packets, and spend a lot of time in softirqs, I'm > pretty sure you'd hit that case of seeing the same softirq re-raised > fairly naturally and quickly. Ok after a quick tracing check, it seems that executing the same softirq vector twice in the same interrupt does not happen without much stress. I'm trying that solution and we'll see what testing will reveal from people's boxes. Thanks.