Received: by 10.223.176.46 with SMTP id f43csp1964193wra; Sun, 21 Jan 2018 08:12:01 -0800 (PST) X-Google-Smtp-Source: AH8x225yeo4GKgwhNrPUmQFzAV22YwUDfc7bfZhCq/V9a6ubssUoNd7lXGV1HT7mHGIh4sFPQxSq X-Received: by 10.101.101.11 with SMTP id x11mr4961896pgv.130.1516551120920; Sun, 21 Jan 2018 08:12:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516551120; cv=none; d=google.com; s=arc-20160816; b=l6OKRfqxmJ/BvMB+oQsT4k3M0sMlqmdoc8CwYuFETYv5v54fFTu6pSndj6pDYVJFyk f1PLRb136QAe9piDtO0fo1oODI2FVMcX5jx8CmHw3R+1rAqd7w2lFEDEmtsWNifKWl3t Rxc0h5b2wAYKQtujTOmPYQX2cXI/h8GMpx0EdEGwls3oGRNtOJ2ulzV1V4OnuIV8q9UP GcpbTRByfSBz6o6y8NFXOGa+yc62jFLP5Ah7MRgvirkp+udMr5wPj0CizfSYHMLJpjrO 0XUpTW8tzKnIJ2tliPw94SdJx2gBpv0i9Xu2TEuRvnefZMBnzdclTdx8v6wBehFRBu7j YIZA== 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:arc-authentication-results; bh=ufBIjQWHTyaTJOyU7fAbIKXy+OIAJJsuKIPVNMk0k7Y=; b=mJ+Jcyo2GAUkFEXXziqAL5DLn4UX1+dVjXwhPh+TTiF7G+lLk+B4nlfsQCEPwJXjEr 3rTyTb8bhTABBmeKGlf0dXHd8bTpCfvK6lmBKsBKmB6hvJNpYvqe+LFGclCWfNqT5US/ 6ImYQ3axH2FpJAlJOXGFlRC3Mmf2RYnI6ckch8zjMVOuuabvtcme3XTV8MEnKGIMMI4b kpvg6+tOim3HQpTp+W3tTG2i52qmSIcH1AHLYNPVg9o61n8hYwkRFPd3OodAkYV2WzfJ QbtDM0Afg//YVh1CkcDt3NLkBarcJ55naujWRXhR4Zn0pGia4ILAVVc2D4yWQhF1WTvY 1RIA== ARC-Authentication-Results: i=1; mx.google.com; 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 37-v6si2638110plc.215.2018.01.21.08.11.45; Sun, 21 Jan 2018 08:12:00 -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; 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 S1750923AbeAUQLX (ORCPT + 99 others); Sun, 21 Jan 2018 11:11:23 -0500 Received: from mail.kernel.org ([198.145.29.99]:59690 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbeAUQLW (ORCPT ); Sun, 21 Jan 2018 11:11:22 -0500 Received: from localhost (i16-les03-th2-31-37-47-191.sfr.lns.abo.bbox.fr [31.37.47.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1B2E521715; Sun, 21 Jan 2018 16:11:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B2E521715 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 Date: Sun, 21 Jan 2018 17:11:17 +0100 From: Frederic Weisbecker To: Pavan Kondeti 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: <20180121161114.GA2879@lerouge> References: <1516376774-24076-1-git-send-email-frederic@kernel.org> <1516376774-24076-3-git-send-email-frederic@kernel.org> <20180120084139.GA8395@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180120084139.GA8395@codeaurora.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > (2) Ksoftirqd thread gets parked when a CPU is hotplugged out. So > there is a gaurantee that the softirq handling never happens on > another CPU. Where as a bounded worker gets detached and the queued > work can run on another CPU. I guess, some special handling is > needed to handle hotplug. Good catch. Funny, I worried a bit about CPU hotplug but I assumed the pending CPU-bound worklets would be simply sync'ed before CPU gets down. Breaking their CPU-bound properties doesn't look sane to me. Anyway, I'll need to make a CPU hotplug hook. Thanks for reporting that!