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 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
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
On Sat, Mar 03, 2007 at 08:32:40PM +0300, Oleg Nesterov wrote:
> 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
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:
> > >
> > > int kthread_should_stop(void)
> > > {
> > >
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:
int kthread_should_stop(void)
{
if
On Sat, Mar 03, 2007 at 08:32:40PM +0300, Oleg Nesterov wrote:
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
On Saturday, 3 March 2007 00:33, 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:
> >
> > int kthread_should_stop(void)
> > {
> > if (kthread_stop_info.k == current)
> >
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:
> >
> > int kthread_should_stop(void)
> > {
> > if (kthread_stop_info.k == current)
>
On 03/02, Paul E. McKenney wrote:
>
> One way to embed try_to_freeze() into kthread_should_stop() might be
> as follows:
>
> int kthread_should_stop(void)
> {
> if (kthread_stop_info.k == current)
> return 1;
> try_to_freeze();
>
Hi Paul,
> We certainly either need to embed try_to_freeze() into kthread_should_stop()
> or add back the rcu_torture_fakewriter(), and rcu_torture_reader()
> components of this patch. ;-)
>
> One way to embed try_to_freeze() into kthread_should_stop() might be
> as follows:
>
> int
On Fri, Mar 02, 2007 at 12:27:30PM +0530, Gautham R Shenoy wrote:
> > From: Paul E. McKenney <[EMAIL PROTECTED]>
> >
> > Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze()
> > call as
> > required.
> >
> > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> >
On Thu, Mar 01, 2007 at 08:54:25PM +0100, Rafael J. Wysocki wrote:
> On Thursday, 1 March 2007 20:38, Anton Blanchard wrote:
> >
> > Hi,
> >
> > > Remove PF_NOFREEZE from the rcutorture thread, adding a
> > > try_to_freeze() call as required.
> >
> > ...
> >
> > > @@ -607,6 +607,7 @@
On Thu, Mar 01, 2007 at 08:54:25PM +0100, Rafael J. Wysocki wrote:
On Thursday, 1 March 2007 20:38, Anton Blanchard wrote:
Hi,
Remove PF_NOFREEZE from the rcutorture thread, adding a
try_to_freeze() call as required.
...
@@ -607,6 +607,7 @@ rcu_torture_writer(void *arg)
On Fri, Mar 02, 2007 at 12:27:30PM +0530, Gautham R Shenoy wrote:
From: Paul E. McKenney [EMAIL PROTECTED]
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze()
call as
required.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki
Hi Paul,
We certainly either need to embed try_to_freeze() into kthread_should_stop()
or add back the rcu_torture_fakewriter(), and rcu_torture_reader()
components of this patch. ;-)
One way to embed try_to_freeze() into kthread_should_stop() might be
as follows:
int
On 03/02, Paul E. McKenney wrote:
One way to embed try_to_freeze() into kthread_should_stop() might be
as follows:
int kthread_should_stop(void)
{
if (kthread_stop_info.k == current)
return 1;
try_to_freeze();
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:
int kthread_should_stop(void)
{
if (kthread_stop_info.k == current)
On Saturday, 3 March 2007 00:33, 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:
int kthread_should_stop(void)
{
if (kthread_stop_info.k == current)
> From: Paul E. McKenney <[EMAIL PROTECTED]>
>
> Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call
> as
> required.
>
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Acked-by: Pavel Machek <[EMAIL
On Thursday, 1 March 2007 20:38, Anton Blanchard wrote:
>
> Hi,
>
> > Remove PF_NOFREEZE from the rcutorture thread, adding a
> > try_to_freeze() call as required.
>
> ...
>
> > @@ -607,6 +607,7 @@ rcu_torture_writer(void *arg)
> > }
> > rcu_torture_current_version++;
>
Hi,
> Remove PF_NOFREEZE from the rcutorture thread, adding a
> try_to_freeze() call as required.
...
> @@ -607,6 +607,7 @@ rcu_torture_writer(void *arg)
> }
> rcu_torture_current_version++;
> oldbatch = cur_ops->completed();
> +
From: Paul E. McKenney <[EMAIL PROTECTED]>
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call as
required.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
From: Paul E. McKenney [EMAIL PROTECTED]
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call as
required.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
Hi,
Remove PF_NOFREEZE from the rcutorture thread, adding a
try_to_freeze() call as required.
...
@@ -607,6 +607,7 @@ rcu_torture_writer(void *arg)
}
rcu_torture_current_version++;
oldbatch = cur_ops-completed();
+ try_to_freeze();
On Thursday, 1 March 2007 20:38, Anton Blanchard wrote:
Hi,
Remove PF_NOFREEZE from the rcutorture thread, adding a
try_to_freeze() call as required.
...
@@ -607,6 +607,7 @@ rcu_torture_writer(void *arg)
}
rcu_torture_current_version++;
From: Paul E. McKenney [EMAIL PROTECTED]
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call
as
required.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
56 matches
Mail list logo
