Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934060AbeAIQD6 (ORCPT + 1 other); Tue, 9 Jan 2018 11:03:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:55096 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933174AbeAIQDz (ORCPT ); Tue, 9 Jan 2018 11:03:55 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DD9721724 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 X-Google-Smtp-Source: ACJfBouhTjpbeR19VL0ocfJZElNdJf0KvQSJb0B6EOrB75dpGbYdbjfE1/etBxXkBA8J6v5II5EJbyghgtXoczFmW5s= MIME-Version: 1.0 In-Reply-To: <20180109133623.10711-2-dima@arista.com> References: <20180109133623.10711-1-dima@arista.com> <20180109133623.10711-2-dima@arista.com> From: Frederic Weisbecker Date: Tue, 9 Jan 2018 17:03:53 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context To: Dmitry Safonov Cc: linux-kernel@vger.kernel.org, 0x7f454c46@gmail.com, Andrew Morton , David Miller , Eric Dumazet , Hannes Frederic Sowa , Ingo Molnar , "Levin, Alexander (Sasha Levin)" , Linus Torvalds , Paolo Abeni , "Paul E. McKenney" , Peter Zijlstra , 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: 2018-01-09 14:36 UTC+01:00, Dmitry Safonov : > Warning: Not merge-ready > > I. Current workflow of ksoftirqd. > Softirqs are processed in the context of ksoftirqd iff they are > being raised very frequently. How it works: > do_softirq() and invoke_softirq() deffer pending softirq iff > ksoftirqd is in runqueue. Ksoftirqd is scheduled mostly in the > end of processed softirqs if 2ms were not enough to process all > pending softirqs. > > Here is pseudo-picture of the workflow (for simplicity on UMP): > ------------- ------------------ ------------------ > | ksoftirqd | | User's process | | Softirqs | > ------------- ------------------ ------------------ > Not scheduled Running > | > o------------------------o > | > __do_softirq() > | > 2ms & softirq pending? > Schedule ksoftirqd > | > Scheduled o------------------------o > | > o--------------------o > | > Running Scheduled > | > o--------------------o > | > Not scheduled Running > > Timegraph for the workflow, > dash (-) means ksoftirqd not scheduled; > equal(=) ksoftirqd is scheduled, a softirq may still be pending > > Pending softirqs > | | | | | | | | | > v v v v | | | | v > Processing o-----o | | | | o--o > softirqs | | | | | | | | > | | | | | | | | > | | | | | | | | > Userspace o-o o=========o | | | | o----o o---------o > <-2ms-> | | | | | | > | v v v v | > Ksoftirqd o----------o > > II. Corner-conditions. > During testing of commit [1] on some non-mainstream driver, > I've found that due to platform specifics, the IRQ is being > raised too late (after softirq has been processed). I'm a bit confused about that part. I would expect the softirq to be raised by the IRQ. So I guess in this scenario the softirq is raised by something else and you expect the upcoming IRQ to handle the softirq, right? (sorry I'm not used to networking code). Thanks. > In result softirqs steal time from userspace process, leaving > it starving for CPU time and never/rarely scheduling ksoftirqd: