On Wed, May 02, 2007 at 08:45:54AM -0600, Eric W. Biederman wrote: > Dean Nelson <[EMAIL PROTECTED]> writes: > > > On Tue, May 01, 2007 at 01:51:41AM -0700, Andrew Morton wrote: > >> I might send ia64-sn-xpc-convert-to-use-kthread-api.patch+fixes off to > >> Tony, as people put quite a bit of review and test effort into that one. > > > > Andrew, I would recommend holding off on sending these xpc patches to > > Tony as the kthread_run()s aren't paired with kthread_stop()s yet. I > > need to generate an additional patch after I've first sorted out how > > best to deal with kthread_stop()'ng XPC's pool of kthreads with Eric. > > Ok. Dean gve me a couple of a day or so. I think I have just worked > through how to directly create kthreads without too much pain. We are > still going to need kthreadd for spawning for a bit because I don't > expect all architectures to change over immediately, but I think > things can be done in a fairly simple low risk manner. > > The changes to the kernel_thread replacement aren't going to be too > bad, pretty much just adding a couple of parameters. It is > copy_thread where things get sticky. > > If we can spawn threads fast enough we don't need a thread pool, I > would rather do that.
I'd typed up some questions for you about the new patch I need to create which I'd just sent to you, so I won't repeat them here. Before proceeding to far with your above changes, you might wait to see the proposal that Robin Holt is putting together for a kthread pool. I'm not sure how spawning a thread (which involves allocation of the task_struct amongst other things, plus scheduling) can beat a wake_up() of an already existing thread for cost time-wise. Dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
