On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote:
> macintosh-mediabay-convert-to-kthread-api.patch
> macintosh-adb-convert-to-the-kthread-api.patch
> macintosh-therm_pm72c-partially-convert-to-kthread-api.patch
> powerpc-pseries-rtasd-convert-to-kthread-api.patch
> powerpc-pseries-eeh-convert-to-kthread-api.patch
>
> Will send to paulus (I already did - does Paul not handle the macintosh
> driver?)
Please don't send out the partial kthread conversions, as they're not
that helpful. Depending on the way we'll let the API evolve a
kthread_create/run not paired by a kthread_stop might be actually harmful.
Please only send along patches that are paired or always built in so that
they don't require stopping at all.
Btw, many of the drivers above should probably go to benh.
There's probably a few more patches falling into this category, these
were just the first one the stick into my eye.
On Tue, 1 May 2007 09:42:45 +0100 Christoph Hellwig <[email protected]> wrote:
> On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote:
> > macintosh-mediabay-convert-to-kthread-api.patch
> > macintosh-adb-convert-to-the-kthread-api.patch
> > macintosh-therm_pm72c-partially-convert-to-kthread-api.patch
> > powerpc-pseries-rtasd-convert-to-kthread-api.patch
> > powerpc-pseries-eeh-convert-to-kthread-api.patch
> >
> > Will send to paulus (I already did - does Paul not handle the macintosh
> > driver?)
>
> Please don't send out the partial kthread conversions, as they're not
> that helpful. Depending on the way we'll let the API evolve a
> kthread_create/run not paired by a kthread_stop might be actually harmful.
>
> Please only send along patches that are paired or always built in so that
> they don't require stopping at all.
>
> Btw, many of the drivers above should probably go to benh.
>
> There's probably a few more patches falling into this category, these
> were just the first one the stick into my eye.
Yes, I think I'll probably drop all of them - I've completely lost track of
which ones are complete, which ones need more work, etc.
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.
On Tue, May 01, 2007 at 01:51:41AM -0700, Andrew Morton wrote:
> On Tue, 1 May 2007 09:42:45 +0100 Christoph Hellwig <[email protected]> wrote:
>
> > On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote:
> > > macintosh-mediabay-convert-to-kthread-api.patch
> > > macintosh-adb-convert-to-the-kthread-api.patch
> > > macintosh-therm_pm72c-partially-convert-to-kthread-api.patch
> > > powerpc-pseries-rtasd-convert-to-kthread-api.patch
> > > powerpc-pseries-eeh-convert-to-kthread-api.patch
> > >
> > > Will send to paulus (I already did - does Paul not handle the macintosh
> > > driver?)
> >
> > Please don't send out the partial kthread conversions, as they're not
> > that helpful. Depending on the way we'll let the API evolve a
> > kthread_create/run not paired by a kthread_stop might be actually harmful.
> >
> > Please only send along patches that are paired or always built in so that
> > they don't require stopping at all.
> >
> > Btw, many of the drivers above should probably go to benh.
> >
> > There's probably a few more patches falling into this category, these
> > were just the first one the stick into my eye.
>
> Yes, I think I'll probably drop all of them - I've completely lost track of
> which ones are complete, which ones need more work, etc.
>
> 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.
Thanks,
Dean
Dean Nelson <[email protected]> writes:
> On Tue, May 01, 2007 at 01:51:41AM -0700, Andrew Morton wrote:
>> > There's probably a few more patches falling into this category, these
>> > were just the first one the stick into my eye.
>>
>> Yes, I think I'll probably drop all of them - I've completely lost track of
>> which ones are complete, which ones need more work, etc.
Andrew as far as dropping them. If all you have is one of my dinky patches
that changes things to use kthread_run feel free, because of the general
necessity of calling kthread_stop I'm going to have to rework those anyway,
and I still have the originals.
If there is something more the we probably want to keep the patch because
someone has actually looked at it and done something useful.
I'm just now starting to work my way through them all again paying a little
closer attention, so I can do a thorough conversion.
>> 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.
Eric
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
Dean Nelson <[email protected]> writes:
> 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.
A reasonable point, although if you don't happen to sleep in the allocations
I suspect time wise it's pretty much a wash.
I have some other reasons I might need the capability of clone a thread
from a non-parent process, and it has the potential to simplify some things
in the kthread case so I'm going to finish investigating, since I believe
I have figured out a path to that target.
Eric
On Wed, 02 May 2007 08:45:54 -0600
[email protected] (Eric W. Biederman) wrote:
> Dean Nelson <[email protected]> writes:
>
> > On Tue, May 01, 2007 at 01:51:41AM -0700, Andrew Morton wrote:
> >> > There's probably a few more patches falling into this category, these
> >> > were just the first one the stick into my eye.
> >>
> >> Yes, I think I'll probably drop all of them - I've completely lost track of
> >> which ones are complete, which ones need more work, etc.
>
> Andrew as far as dropping them. If all you have is one of my dinky patches
> that changes things to use kthread_run feel free, because of the general
> necessity of calling kthread_stop I'm going to have to rework those anyway,
> and I still have the originals.
>
I gave up and dropped them all - let's have another run at it. Possibly
some of them were complete and didn't deserve dropping, in which case you
can send them straight back at me.
Andrew Morton <[email protected]> writes:
> I gave up and dropped them all - let's have another run at it. Possibly
> some of them were complete and didn't deserve dropping, in which case you
> can send them straight back at me.
Sounds like a plan.
Eric