Re: "partical" kthread conversion

[Dean Nelson]

On Wed, May 02, 2007 at 08:45:54AM -0600, Eric W. Biederman wrote:
> Dean Nelson <dcn@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/