Messages in this thread | | | Subject | Re: + work_on_cpu-rewrite-it-to-create-a-kernel-thread-on-demand.patch added to -mm tree | From | (Eric W. Biederman) | Date | Thu, 12 Feb 2009 15:04:31 -0800 |
| |
Andrew Morton <akpm@linux-foundation.org> 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
| |