Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935651AbeAKTsb (ORCPT + 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 ); Thu, 11 Jan 2018 14:48:29 -0500 X-Google-Smtp-Source: ACJfBotQqOQeYWvjInkML14sneqoq4suuZJe2QUP0PtQdfC5U9yZ0pMTZsURqMlY5WJdx2y3DyYedCUj+8zcw+9j6p0= MIME-Version: 1.0 In-Reply-To: References: <20180109133623.10711-1-dima@arista.com> <20180109133623.10711-2-dima@arista.com> <1515620880.3350.44.camel@arista.com> <20180111032232.GA11633@lerouge> <20180111044456.GC11633@lerouge> <1515681091.3039.21.camel@arista.com> <20180111163204.GE6176@hirez.programming.kicks-ass.net> From: Eric Dumazet Date: Thu, 11 Jan 2018 11:48:26 -0800 Message-ID: Subject: Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context To: Linus Torvalds Cc: Peter Zijlstra , Dmitry Safonov , Frederic Weisbecker , LKML , Dmitry Safonov <0x7f454c46@gmail.com>, Andrew Morton , David Miller , Frederic Weisbecker , Hannes Frederic Sowa , Ingo Molnar , "Levin, Alexander (Sasha Levin)" , Paolo Abeni , "Paul E. McKenney" , Radu Rendec , Rik van Riel , Stanislaw Gruszka , Thomas Gleixner , Wanpeng Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 11, 2018 at 11:43 AM, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 11:15 AM, Eric Dumazet 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.