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;
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FE6720C48
Date:   Thu, 18 Jan 2018 05:09:24 +0100
From:   Frederic Weisbecker <frederic@kernel.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Mauro Carvalho Chehab <mchehab@s-opensource.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Levin Alexander <alexander.levin@verizon.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Hannes Frederic Sowa <hannes@stressinduktion.org>,
        "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>,
        Dmitry Safonov <dima@arista.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Eric Dumazet <edumazet@google.com>,
        Radu Rendec <rrendec@arista.com>,
        Ingo Molnar <mingo@kernel.org>,
        Stanislaw Gruszka <sgruszka@redhat.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Rik van Riel <riel@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Miller <davem@davemloft.net>
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>
 <CA+55aFzojENpf+-fEhkNL_RaQbtC0FoB6x7DDXqZCScCOAUmQg@mail.gmail.com>
 <20180118025539.GA20310@lerouge>
 <CA+55aFwzFn=gbqLmmc=R9Tv1bX1GoSWsbcTKzG=nrJZKsj9nVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFwzFn=gbqLmmc=R9Tv1bX1GoSWsbcTKzG=nrJZKsj9nVw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jan 17, 2018 at 07:09:39PM -0800, Linus Torvalds wrote:
> On Wed, Jan 17, 2018 at 6:55 PM, Frederic Weisbecker
> <frederic@kernel.org> 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.