From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S935651AbeAKTsb (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Thu, 11 Jan 2018 14:48:31 -0500
Received: from mail-wr0-f193.google.com ([209.85.128.193]:34627 "EHLO
        mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932684AbeAKTs3 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 11 Jan 2018 14:48:29 -0500
X-Google-Smtp-Source: ACJfBotQqOQeYWvjInkML14sneqoq4suuZJe2QUP0PtQdfC5U9yZ0pMTZsURqMlY5WJdx2y3DyYedCUj+8zcw+9j6p0=
MIME-Version: 1.0
In-Reply-To: <CA+55aFyZPzkjwkLXWWXp3KUfLD7MUtGxSu1Q6vc0O5i9Ea6ZKw@mail.gmail.com>
References: <20180109133623.10711-1-dima@arista.com> <20180109133623.10711-2-dima@arista.com>
 <CANn89iK3M97MN0Pf3nXb+UAqqhUWOdSthHRBTYCwP75Ax_hO8Q@mail.gmail.com>
 <1515620880.3350.44.camel@arista.com> <CA+55aFyKKt4_5RT9RT8ZH-W26hC8=AvRYf8YxBm98dGSWwFs8g@mail.gmail.com>
 <20180111032232.GA11633@lerouge> <CA+55aFx_3zwQJ0YbDCL4YxpWEWhcEZfJnn42LzWBWDi3h1VdGA@mail.gmail.com>
 <20180111044456.GC11633@lerouge> <1515681091.3039.21.camel@arista.com>
 <CANn89i+mVmzrZ14Kttt=J0wsDOMHhm8CHiMRLQwEZXMxiVpftg@mail.gmail.com>
 <20180111163204.GE6176@hirez.programming.kicks-ass.net> <CA+55aFwc3CP-sKOyVvaLab3azmr3LnPfADnGJXDcxYz9dT75=A@mail.gmail.com>
 <CANn89i+ZTLtA5ZLRAbCgM_Cx-2xiwRbDXM4x=-QiM78r5ptcqg@mail.gmail.com> <CA+55aFyZPzkjwkLXWWXp3KUfLD7MUtGxSu1Q6vc0O5i9Ea6ZKw@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 11 Jan 2018 11:48:26 -0800
Message-ID: <CANn89iJzekwx_Hs0t0O==+gwAfqMyVHBg=gemayZZJXb4bYJdQ@mail.gmail.com>
Subject: Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Dmitry Safonov <dima@arista.com>,
        Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Dmitry Safonov <0x7f454c46@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Miller <davem@davemloft.net>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Hannes Frederic Sowa <hannes@stressinduktion.org>,
        Ingo Molnar <mingo@kernel.org>,
        "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>,
        Paolo Abeni <pabeni@redhat.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Radu Rendec <rrendec@arista.com>,
        Rik van Riel <riel@redhat.com>,
        Stanislaw Gruszka <sgruszka@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Wanpeng Li <wanpeng.li@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

On Thu, Jan 11, 2018 at 11:43 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jan 11, 2018 at 11:15 AM, Eric Dumazet <edumazet@google.com> wrote:
>>
>> How are we supposed to know this particular workload is problematic
>> for innocent user threads on the same cpu ?
>
> Put that question another way: how is the _softirq_ code supposed to know?

That was the purpose on the last patch : As soon as ksoftirqd is scheduled
(by some kind of jitter in the 99,000 pps workload, or antagonist wakeup),
we then switch to a mode where process scheduler can make decisions
based on threads prios and cpu usage.

Then, as soon as the load was able to finish in its quantum the
pending irqs, we re-enter the mode
where softirq are immediately serviced.

>
> If you can't know, then the softirq code definitely can't know either.
> It has even less information. It doesn't know about NAPI, it doesn't
> know about irq steering, it doesn't know anything at all.

That is true.