On Mon 2007-03-12 17:58:05, Paul E. McKenney wrote:
> On Mon, Mar 12, 2007 at 11:39:06PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > Looks good to me! The other kthread_should_stop() calls in
> > > > > rcutorture.c should also become
> > > > > kthread_should_top_check_freeze().
> >
> > > >
Hi!
> > Do not do it, then. Confusion it causes is not worth saving one line
> > of code.
> >
> > You do less typing, but the resulting code is _less_ readable, not
> > more.
>
> Then please document it _clearly_ with the kthread code somewhere. The
> reason I brought this up is I had no idea
Hi!
Do not do it, then. Confusion it causes is not worth saving one line
of code.
You do less typing, but the resulting code is _less_ readable, not
more.
Then please document it _clearly_ with the kthread code somewhere. The
reason I brought this up is I had no idea we had to put
On Mon 2007-03-12 17:58:05, Paul E. McKenney wrote:
On Mon, Mar 12, 2007 at 11:39:06PM +0100, Pavel Machek wrote:
Hi!
Looks good to me! The other kthread_should_stop() calls in
rcutorture.c should also become
kthread_should_top_check_freeze().
Why is it useful?
On Mon, Mar 12, 2007 at 11:39:06PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Looks good to me! The other kthread_should_stop() calls in
> > > > rcutorture.c should also become
> > > > kthread_should_top_check_freeze().
>
> > > Why is it useful?
> >
> > Because we want to avoid repeating
> >
On Mon, Mar 12, 2007 at 11:39:06PM +0100, Pavel Machek wrote:
Hi!
Looks good to me! The other kthread_should_stop() calls in
rcutorture.c should also become
kthread_should_top_check_freeze().
Why is it useful?
Because we want to avoid repeating
while
On Tue, Mar 13, 2007 at 03:28:08PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Mar 13, 2007 at 09:16:29AM +, Christoph Hellwig wrote:
> > > Document as well in the kernel_thread() API, as I notice people still
> > > use kernel_thread() some places (ex: rtasd.c in powerpc arch)?
> >
> > They
On Tue, Mar 13, 2007 at 09:16:29AM +, Christoph Hellwig wrote:
> > Document as well in the kernel_thread() API, as I notice people still
> > use kernel_thread() some places (ex: rtasd.c in powerpc arch)?
>
> They shouldn't use kernel_thread.
Hmm ..that needs to be documented as well then! I
On Tue, Mar 13, 2007 at 08:44:11AM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Mar 12, 2007 at 05:45:24PM -0500, Anton Blanchard wrote:
> > Then please document it _clearly_ with the kthread code somewhere.
>
> Document as well in the kernel_thread() API, as I notice people still
> use
On Tue, Mar 13, 2007 at 08:44:11AM +0530, Srivatsa Vaddagiri wrote:
On Mon, Mar 12, 2007 at 05:45:24PM -0500, Anton Blanchard wrote:
Then please document it _clearly_ with the kthread code somewhere.
Document as well in the kernel_thread() API, as I notice people still
use kernel_thread()
On Tue, Mar 13, 2007 at 09:16:29AM +, Christoph Hellwig wrote:
Document as well in the kernel_thread() API, as I notice people still
use kernel_thread() some places (ex: rtasd.c in powerpc arch)?
They shouldn't use kernel_thread.
Hmm ..that needs to be documented as well then! I can
On Tue, Mar 13, 2007 at 03:28:08PM +0530, Srivatsa Vaddagiri wrote:
On Tue, Mar 13, 2007 at 09:16:29AM +, Christoph Hellwig wrote:
Document as well in the kernel_thread() API, as I notice people still
use kernel_thread() some places (ex: rtasd.c in powerpc arch)?
They shouldn't use
On Tue, Mar 13, 2007 at 10:57:16AM +0530, Gautham R Shenoy wrote:
> CPU_DEAD:
> thaw_process(p);
> kthread_stop(p);
> p = NULL;
This neednt guarantee that the thread will see the stop request before
it exits the kthread_should_stop_freeze() function. There will always
be races .. So the only safe
On Sun, Mar 11, 2007 at 06:49:08PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
> > On 03/02, Paul E. McKenney wrote:
> > >
> > > On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
> > > > On 03/02, Paul E. McKenney wrote:
> > > > >
> > > > >
On Mon, Mar 12, 2007 at 05:45:24PM -0500, Anton Blanchard wrote:
> Then please document it _clearly_ with the kthread code somewhere.
Document as well in the kernel_thread() API, as I notice people still
use kernel_thread() some places (ex: rtasd.c in powerpc arch)?
> The reason I brought this
> Do not do it, then. Confusion it causes is not worth saving one line
> of code.
>
> You do less typing, but the resulting code is _less_ readable, not
> more.
Then please document it _clearly_ with the kthread code somewhere. The
reason I brought this up is I had no idea we had to put the
Hi!
> > > Looks good to me! The other kthread_should_stop() calls in
> > > rcutorture.c should also become
> > > kthread_should_top_check_freeze().
> > Why is it useful?
>
> Because we want to avoid repeating
>
> while (!kthread_should_stop()) {
> try_to_freeze();
> ...
> }
>
>
On Monday, 12 March 2007 14:24, Cedric Le Goater wrote:
> Oleg Nesterov wrote:
> > On 03/12, Rafael J. Wysocki wrote:
> >> On Monday, 12 March 2007 09:14, Pavel Machek wrote:
> >>> Can we get better name for this function?
> >> Well, I took the name from the Oleg's message. Can you please suggest
Oleg Nesterov wrote:
> On 03/12, Rafael J. Wysocki wrote:
>> On Monday, 12 March 2007 09:14, Pavel Machek wrote:
>>> Can we get better name for this function?
>> Well, I took the name from the Oleg's message. Can you please suggest
>> something?
>
> Well, kthread_should_stop_check_freeze() is
On 03/12, Rafael J. Wysocki wrote:
>
> On Monday, 12 March 2007 09:14, Pavel Machek wrote:
> >
> > Can we get better name for this function?
>
> Well, I took the name from the Oleg's message. Can you please suggest
> something?
Well, kthread_should_stop_check_freeze() is really awful, I agree
Hi,
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
> Hi!
>
> > > > I personally think we should do the opposite, add
> > > > kthread_should_stop_check_freeze()
> > > > or something. kthread_should_stop() is like signal_pending(), we can use
> > > > it under spin_lock (and it is probably
Hi!
> > > I personally think we should do the opposite, add
> > > kthread_should_stop_check_freeze()
> > > or something. kthread_should_stop() is like signal_pending(), we can use
> > > it under spin_lock (and it is probably used this way by some out-of-tree
> > > driver). The new helper is
Hi!
I personally think we should do the opposite, add
kthread_should_stop_check_freeze()
or something. kthread_should_stop() is like signal_pending(), we can use
it under spin_lock (and it is probably used this way by some out-of-tree
driver). The new helper is obviously
Hi,
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Hi!
I personally think we should do the opposite, add
kthread_should_stop_check_freeze()
or something. kthread_should_stop() is like signal_pending(), we can use
it under spin_lock (and it is probably used this way by
On 03/12, Rafael J. Wysocki wrote:
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Can we get better name for this function?
Well, I took the name from the Oleg's message. Can you please suggest
something?
Well, kthread_should_stop_check_freeze() is really awful, I agree :)
We
Oleg Nesterov wrote:
On 03/12, Rafael J. Wysocki wrote:
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Can we get better name for this function?
Well, I took the name from the Oleg's message. Can you please suggest
something?
Well, kthread_should_stop_check_freeze() is really awful,
On Monday, 12 March 2007 14:24, Cedric Le Goater wrote:
Oleg Nesterov wrote:
On 03/12, Rafael J. Wysocki wrote:
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Can we get better name for this function?
Well, I took the name from the Oleg's message. Can you please suggest
something?
Hi!
Looks good to me! The other kthread_should_stop() calls in
rcutorture.c should also become
kthread_should_top_check_freeze().
Why is it useful?
Because we want to avoid repeating
while (!kthread_should_stop()) {
try_to_freeze();
...
}
in many places?
Do
Do not do it, then. Confusion it causes is not worth saving one line
of code.
You do less typing, but the resulting code is _less_ readable, not
more.
Then please document it _clearly_ with the kthread code somewhere. The
reason I brought this up is I had no idea we had to put the freezer
On Mon, Mar 12, 2007 at 05:45:24PM -0500, Anton Blanchard wrote:
Then please document it _clearly_ with the kthread code somewhere.
Document as well in the kernel_thread() API, as I notice people still
use kernel_thread() some places (ex: rtasd.c in powerpc arch)?
The reason I brought this up
On Sun, Mar 11, 2007 at 06:49:08PM +0100, Rafael J. Wysocki wrote:
On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
One way to embed
On Tue, Mar 13, 2007 at 10:57:16AM +0530, Gautham R Shenoy wrote:
CPU_DEAD:
thaw_process(p);
kthread_stop(p);
p = NULL;
This neednt guarantee that the thread will see the stop request before
it exits the kthread_should_stop_freeze() function. There will always
be races .. So the only safe way
On Sun, Mar 11, 2007 at 06:49:08PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
> > On 03/02, Paul E. McKenney wrote:
> > >
> > > On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
> > > > On 03/02, Paul E. McKenney wrote:
> > > > >
> > > > >
On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
> On 03/02, Paul E. McKenney wrote:
> >
> > On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
> > > On 03/02, Paul E. McKenney wrote:
> > > >
> > > > One way to embed try_to_freeze() into kthread_should_stop() might be
> > > > as
On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
One way to embed try_to_freeze() into kthread_should_stop() might be
as follows:
On Sun, Mar 11, 2007 at 06:49:08PM +0100, Rafael J. Wysocki wrote:
On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
One way to embed
36 matches
Mail list logo
