Received: by 10.223.176.46 with SMTP id f43csp2041198wra; Sun, 21 Jan 2018 09:52:01 -0800 (PST) X-Google-Smtp-Source: AH8x2274kPvEm2/r58T5/I94+Oi4848FB8JHTSJFrT4QBHWFUv8pm0XljwtaXjVQmMQlmopqx9QS X-Received: by 10.99.110.200 with SMTP id j191mr1557159pgc.348.1516557121497; Sun, 21 Jan 2018 09:52:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516557121; cv=none; d=google.com; s=arc-20160816; b=QCvlHkXBkuh8GklysyixB+t4Rpvbyd50aaYOyw/NW6ImLY9rnu2Uai4aQLuPD0tJv0 hM2W/uAX/YoqzsxY6ouolVX6lMWsXNJPvzUwUyUMo3+4KldRli/fCEM5MIx/XX+IlHoC 7cDs7hjDtPc9uRXlmff1IDs2ipazsl+/0rd370Hmxxk40wt/WEPkpTf1y336lrx8IAqu aLdXGZXbRpc0SxyGh7KNkI+sqj90mMNnGETAE4zyeoLmNjnlb5GAY0kGfQMH6081ilyg NLDjfmXU4qy+RTaFlFW/itXlJd20iXAwTOolSJuAn6n5EUy9d+rbHlwO1RLl0T4RjHYG PcQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=vlgSGzpvuBmKkHL74klTxYJOdOvUZxJ97uIOZb+mtCk=; b=ERbYPQDgNW/CV7r+9OkNXWNy1Ux80VtFGdjcKMCVSXBljajh2z6NiS89SbJMIVVICt RL35WQZZeEGrjHLDdjCk3JLM0JZVf/3UWLPROlOra7RdksOGdM1Wk9zOZT/+BP8ASKRX Qwzwg4nNi6hIXdDAeZVV2ISw43dJCEweB/Nf6vlBZ4EC9Q42P8GaHMfmAa+UFaSgdEKm UJsXP4WneAhyMk2+FTIa8m3SvGAcyXkts0BmEhlFBcrgBaBFePEaJxS/ddoFWE0Mh8oG ojVNpRvu1wO9LdWPf0B75q4E9EPu65ycdZ7S47+tZtk3Og/kUtsYvXMQllv1kJlPW/C/ JR5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=eCdpo0n8; dkim=pass header.i=@codeaurora.org header.s=default header.b=AlGGnN1I; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23si13943693pfg.61.2018.01.21.09.51.47; Sun, 21 Jan 2018 09:52:01 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=eCdpo0n8; dkim=pass header.i=@codeaurora.org header.s=default header.b=AlGGnN1I; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751354AbeAURuw (ORCPT + 99 others); Sun, 21 Jan 2018 12:50:52 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:48160 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111AbeAURuu (ORCPT ); Sun, 21 Jan 2018 12:50:50 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5D65B6090E; Sun, 21 Jan 2018 17:50:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1516557050; bh=x6wue5amfqSWqjTLlmU7xPjPix1FxcmfcgzqQigoExg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eCdpo0n8BDK0BGDn8tS1L59gtNxfg4lTpiKTIt85ww/OG8kQNBIxQKeZCqvmiAS0J 8gI5KAdYLpoBwNsweCJ9SbfGPkd3C1wrOp2ISF0M5xYkixDrGZlRw8yklKy/EjL/Q5 aOBnVVtzapNK8BtLHY314qwUeuNrdxmz/F4VqhZ8= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from codeaurora.org (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pkondeti@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 0D3BC6074C; Sun, 21 Jan 2018 17:50:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1516557049; bh=x6wue5amfqSWqjTLlmU7xPjPix1FxcmfcgzqQigoExg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AlGGnN1I6fx/9a3OQpX9RGUN1F3tjFmMMG0e/x8Uzn7aYmPSJgfesSOxxmroELqfA 3isuMF2J+nYbHjFEmKB3a4uBzCfCvuoWiyL02jJgyyQI2M2hnv38zPiYpcK2C95CWQ uRj44sCUdLcx6ZURgZaj4+uWMUsX5dsDebQ+XKk0= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0D3BC6074C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=pkondeti@codeaurora.org Date: Sun, 21 Jan 2018 23:20:40 +0530 From: Pavan Kondeti To: Frederic Weisbecker Cc: LKML , Levin Alexander , Peter Zijlstra , Mauro Carvalho Chehab , Linus Torvalds , Hannes Frederic Sowa , "Paul E . McKenney" , Wanpeng Li , Dmitry Safonov , Thomas Gleixner , Andrew Morton , Paolo Abeni , Radu Rendec , Ingo Molnar , Stanislaw Gruszka , Rik van Riel , Eric Dumazet , David Miller Subject: Re: [RFC PATCH 2/4] softirq: Per vector deferment to workqueue Message-ID: <20180121175040.GA30677@codeaurora.org> References: <1516376774-24076-1-git-send-email-frederic@kernel.org> <1516376774-24076-3-git-send-email-frederic@kernel.org> <20180120084139.GA8395@codeaurora.org> <20180121161114.GA2879@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180121161114.GA2879@lerouge> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 21, 2018 at 05:11:17PM +0100, Frederic Weisbecker wrote: > On Sat, Jan 20, 2018 at 02:11:39PM +0530, Pavan Kondeti wrote: > > Hi Pavan, > > > > I have couple questions/comments. > > > > (1) Since the work is queued on a bounded per-cpu worker, we may run > > into a deadlock if a TASKLET is killed from another work running on > > the same bounded per-cpu worker. > > > > For example, > > > > (1) Schedule a TASKLET on CPU#0 from IRQ. > > (2) Another IRQ comes on the same CPU and we queue a work to kill > > the TASKLET. > > (3) The TASKLET vector is deferred to workqueue. > > (4) We run the TASKLET kill work and wait for the TASKLET to finish, > > which won't happen. > > > > We can fix this by queueing the TASKLET kill work on an unbounded > > workqueue so that this runs in parallel with TASKLET vector work. > > > > Just wanted to know if we have to be aware of this *condition*. > > But IIRC the workqueues have several workers per CPU so the tasklet to > be killed can run while the tasklet killer yields. > AFAIK, the work items queued via schedule_work_on() goes to the system_wq which is bounded to a CPU with concurrency restrictions. If any work item (in this case tasklet kill) is getting executed on this bounded worker, the next items have to wait. The forward progress happens only when the current work is finished or enters sleep. This also makes me wonder what happens if a CPU hogging work gets executed on the system_wq while softirq work is pending? The softirq work gets starved which won't happen now with ksoftirqd design. Ideally the CPU hogging work should not be queued on the system_wq and instead should be queued on CPU intenstive workqueue (WQ_CPU_INTENSIVE) to exempt from concurrency management. May be we need some special workqueue which is bounded but not subjected to concurrency management. -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.