From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759833AbZBLXFI (ORCPT ); Thu, 12 Feb 2009 18:05:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756963AbZBLXEv (ORCPT ); Thu, 12 Feb 2009 18:04:51 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:45318 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756528AbZBLXEu (ORCPT ); Thu, 12 Feb 2009 18:04:50 -0500 To: Andrew Morton Cc: fweisbec@gmail.com, mingo@elte.hu, linux-kernel@vger.kernel.org, oleg@redhat.com, travis@sgi.com, a.p.zijlstra@chello.nl, rusty@rustcorp.com.au Subject: Re: + work_on_cpu-rewrite-it-to-create-a-kernel-thread-on-demand.patch added to -mm tree References: <200902031058.n13AwOoK016719@imap1.linux-foundation.org> <20090203121147.GB19979@elte.hu> <20090203112529.26e6bf76.akpm@linux-foundation.org> <20090212124835.2fc41620.akpm@linux-foundation.org> <20090212142314.9ab6ad6f.akpm@linux-foundation.org> From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 12 Feb 2009 15:04:31 -0800 In-Reply-To: <20090212142314.9ab6ad6f.akpm@linux-foundation.org> (Andrew Morton's message of "Thu\, 12 Feb 2009 14\:23\:14 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=67.169.126.145;;;frm=ebiederm@xmission.com;;;spf=neutral X-SA-Exim-Connect-IP: 67.169.126.145 X-SA-Exim-Rcpt-To: akpm@linux-foundation.org, rusty@rustcorp.com.au, a.p.zijlstra@chello.nl, travis@sgi.com, oleg@redhat.com, linux-kernel@vger.kernel.org, mingo@elte.hu, fweisbec@gmail.com X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: No (on in01.mta.xmission.com); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton writes: > On Thu, 12 Feb 2009 14:13:06 -0800 > ebiederm@xmission.com (Eric W. Biederman) wrote: > >> >> I should follow up and say that the reason I care right now, is I am >> digging into pci hotplug. One of the issues I'm fighting is that >> currently I appear to need a dedicated kernel thread for each pci >> hotplug slot. It gets easy to deadlock the kernel hotplugging >> a hotplug controller otherwise. >> > > um, ok, if you say so... > > I'd have thought that a short-lived kernel thread would be appropriate, > if poss. Physical hotplug of a PCI device isn't a high-frequency > operation. Oh. I'm working to find a way to get there. The trouble is I have kick off all of this from interrupt context. > The new-fangled work_on_cpu() could do that, or maybe the new-fangled > kernel/async.c code. I will have to look. A shared workqueue threatens to deadlock when I try and hotunplug a hotplug slot. Running cancel_work_sync for work in your current workqueue is the problem I had. Maybe some of the rest of the solutions won't have that kind of problem. I have this crazy thought that workqueues should just be fixed to fork a short lived kernel thread for each request they process, and then we don't have to worry about stuff blocking indefinitely. I think that will allow us to kill off explicitly named workqueues as well. Eric