[PATCH 0/3] Suggested patches for v3.0.9-rt26

[PATCH 0/3] Suggested patches for v3.0.9-rt26

[John Kacur]

Hello Steve Rostedt and rt-folks

I would also suggest the following three patches for v3.0.9-rt26 in addition
to the ones you already posted.

The two patches from Thomas Gleixner are in v3.2-rc2-rt3
and the patch from Paul McKenney is upstream. (non-rt)

You can pull them from my tree.
git://git.kernel.org:/pub/scm/linux/kernel/git/jkacur/linux-rt.git
branch: v3.0-rt-fixes

Thank You
John Kacur

Paul E. McKenney (1):
  rcu: Drive configuration directly from SMP and PREEMPT

Thomas Gleixner (2):
  rcu-more-fallout.patch
  sysctl-include-fix.patch

 include/linux/sysctl.h |    1 +
 init/Kconfig           |    6 +++---
 kernel/rcutiny.c       |    2 ++
 3 files changed, 6 insertions(+), 3 deletions(-)

-- 
1.7.2.3

[PATCH 1/3] rcu-more-fallout.patch

[John Kacur]

From: Thomas Gleixner <tglx@linutronix.de>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cherry-picked for v3.0-rt and fixed minor merge conflict
Signed-off-by: John Kacur <jkacur@redhat.com>
---
 kernel/rcutiny.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
index 7bbac7d..f1e4bee 100644
--- a/kernel/rcutiny.c
+++ b/kernel/rcutiny.c
@@ -271,6 +271,7 @@ void call_rcu_sched(struct rcu_head *head, void (*func)(struct rcu_head *rcu))
 }
 EXPORT_SYMBOL_GPL(call_rcu_sched);
 
+#ifndef CONFIG_PREEMPT_RT_FULL
 /*
  * Post an RCU bottom-half callback to be invoked after any subsequent
  * quiescent state.
@@ -280,6 +281,7 @@ void call_rcu_bh(struct rcu_head *head, void (*func)(struct rcu_head *rcu))
 	__call_rcu(head, func, &rcu_bh_ctrlblk);
 }
 EXPORT_SYMBOL_GPL(call_rcu_bh);
+#endif
 
 void rcu_barrier_bh(void)
 {
-- 
1.7.2.3

[PATCH 2/3] sysctl-include-fix.patch

[John Kacur]

From: Thomas Gleixner <tglx@linutronix.de>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cherry-picked for v3.0-rt and fixed minor merge conflict
Signed-off-by: John Kacur <jkacur@redhat.com>
---
 include/linux/sysctl.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 11684d9..92b99dd 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -931,6 +931,7 @@ enum
 #ifdef __KERNEL__
 #include <linux/list.h>
 #include <linux/rcupdate.h>
+#include <linux/atomic.h>
 
 /* For the /proc/sys support */
 struct ctl_table;
-- 
1.7.2.3

[PATCH 3/3] rcu: Drive configuration directly from SMP and PREEMPT

[John Kacur]

From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

This commit eliminates the possibility of running TREE_PREEMPT_RCU
when SMP=n and of running TINY_RCU when PREEMPT=y.  People who really
want these combinations can hand-edit init/Kconfig, but eliminating
them as choices for production systems reduces the amount of testing
required.  It will also allow cutting out a few #ifdefs.

Note that running TREE_RCU and TINY_RCU on single-CPU systems using
SMP-built kernels is still supported.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 8008e129dc90ff4f7a56cb033d6bd042afe3ed52 upstream
Cherry-picked for v3.0-rt and fixed-up merge conflicts
Note: This makes the depends lines for these options in init/Kconfig for v3.0-rt
match those for v3.2-rc2-rt3
Signed-off-by: John Kacur <jkacur@redhat.com>
---
 init/Kconfig |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 89e40a4..5c1147e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -391,7 +391,7 @@ config TREE_RCU
 
 config TREE_PREEMPT_RCU
 	bool "Preemptible tree-based hierarchical RCU"
-	depends on PREEMPT
+	depends on PREEMPT && SMP
 	help
 	  This option selects the RCU implementation that is
 	  designed for very large SMP systems with hundreds or
@@ -401,7 +401,7 @@ config TREE_PREEMPT_RCU
 
 config TINY_RCU
 	bool "UP-only small-memory-footprint RCU"
-	depends on !SMP && !PREEMPT_RT_FULL
+	depends on !PREEMPT && !SMP
 	help
 	  This option selects the RCU implementation that is
 	  designed for UP systems from which real-time response
@@ -410,7 +410,7 @@ config TINY_RCU
 
 config TINY_PREEMPT_RCU
 	bool "Preemptible UP-only small-memory-footprint RCU"
-	depends on !SMP && PREEMPT && !PREEMPT_RT_FULL
+	depends on PREEMPT && !SMP
 	help
 	  This option selects the RCU implementation that is designed
 	  for real-time UP systems.  This option greatly reduces the
-- 
1.7.2.3

Re: [PATCH 1/3] rcu-more-fallout.patch

[Steven Rostedt]

On Sat, 2011-11-19 at 13:50 +0100, John Kacur wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cherry-picked for v3.0-rt and fixed minor merge conflict
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
>  kernel/rcutiny.c |    2 ++

Is this really needed?

>From init/Kconfig:

config TINY_RCU
	bool "UP-only small-memory-footprint RCU"
	depends on !SMP && !PREEMPT_RT_FULL


This code isn't even compiled when PREEMPT_RT_FULL is set.

-- Steve

>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/rcutiny.c b/kernel/rcutiny.c
> index 7bbac7d..f1e4bee 100644
> --- a/kernel/rcutiny.c
> +++ b/kernel/rcutiny.c
> @@ -271,6 +271,7 @@ void call_rcu_sched(struct rcu_head *head, void (*func)(struct rcu_head *rcu))
>  }
>  EXPORT_SYMBOL_GPL(call_rcu_sched);
>  
> +#ifndef CONFIG_PREEMPT_RT_FULL
>  /*
>   * Post an RCU bottom-half callback to be invoked after any subsequent
>   * quiescent state.
> @@ -280,6 +281,7 @@ void call_rcu_bh(struct rcu_head *head, void (*func)(struct rcu_head *rcu))
>  	__call_rcu(head, func, &rcu_bh_ctrlblk);
>  }
>  EXPORT_SYMBOL_GPL(call_rcu_bh);
> +#endif
>  
>  void rcu_barrier_bh(void)
>  {

Re: [PATCH 2/3] sysctl-include-fix.patch

[Steven Rostedt]

On Sat, 2011-11-19 at 13:50 +0100, John Kacur wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cherry-picked for v3.0-rt and fixed minor merge conflict
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
>  include/linux/sysctl.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Why is this needed? Did something break without it?

And if so, what?

-- Steve

> 
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 11684d9..92b99dd 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysctl.h
> @@ -931,6 +931,7 @@ enum
>  #ifdef __KERNEL__
>  #include <linux/list.h>
>  #include <linux/rcupdate.h>
> +#include <linux/atomic.h>
>  
>  /* For the /proc/sys support */
>  struct ctl_table;

Re: [PATCH 3/3] rcu: Drive configuration directly from SMP and PREEMPT

[Steven Rostedt]

On Sat, 2011-11-19 at 13:50 +0100, John Kacur wrote:
> From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> This commit eliminates the possibility of running TREE_PREEMPT_RCU
> when SMP=n and of running TINY_RCU when PREEMPT=y.  People who really
> want these combinations can hand-edit init/Kconfig, but eliminating
> them as choices for production systems reduces the amount of testing
> required.  It will also allow cutting out a few #ifdefs.
> 
> Note that running TREE_RCU and TINY_RCU on single-CPU systems using
> SMP-built kernels is still supported.

With this patch, I can see the need for the first patch (although
there's things broken even for that), but is this really a stable fix?

This looks more of an added feature than a bug fix. It's a bug fix if we
consider running tree_rcu on UP a bug. Or better stated, will it break
anything if we do that?

-- Steve

> 
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> commit 8008e129dc90ff4f7a56cb033d6bd042afe3ed52 upstream
> Cherry-picked for v3.0-rt and fixed-up merge conflicts
> Note: This makes the depends lines for these options in init/Kconfig for v3.0-rt
> match those for v3.2-rc2-rt3
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
>  init/Kconfig |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 89e40a4..5c1147e 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -391,7 +391,7 @@ config TREE_RCU
>  
>  config TREE_PREEMPT_RCU
>  	bool "Preemptible tree-based hierarchical RCU"
> -	depends on PREEMPT
> +	depends on PREEMPT && SMP
>  	help
>  	  This option selects the RCU implementation that is
>  	  designed for very large SMP systems with hundreds or
> @@ -401,7 +401,7 @@ config TREE_PREEMPT_RCU
>  
>  config TINY_RCU
>  	bool "UP-only small-memory-footprint RCU"
> -	depends on !SMP && !PREEMPT_RT_FULL
> +	depends on !PREEMPT && !SMP
>  	help
>  	  This option selects the RCU implementation that is
>  	  designed for UP systems from which real-time response
> @@ -410,7 +410,7 @@ config TINY_RCU
>  
>  config TINY_PREEMPT_RCU
>  	bool "Preemptible UP-only small-memory-footprint RCU"
> -	depends on !SMP && PREEMPT && !PREEMPT_RT_FULL
> +	depends on PREEMPT && !SMP
>  	help
>  	  This option selects the RCU implementation that is designed
>  	  for real-time UP systems.  This option greatly reduces the

Re: [PATCH 3/3] rcu: Drive configuration directly from SMP and PREEMPT

[John Kacur]

On Mon, Nov 21, 2011 at 5:10 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sat, 2011-11-19 at 13:50 +0100, John Kacur wrote:
>> From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>
>> This commit eliminates the possibility of running TREE_PREEMPT_RCU
>> when SMP=n and of running TINY_RCU when PREEMPT=y.  People who really
>> want these combinations can hand-edit init/Kconfig, but eliminating
>> them as choices for production systems reduces the amount of testing
>> required.  It will also allow cutting out a few #ifdefs.
>>
>> Note that running TREE_RCU and TINY_RCU on single-CPU systems using
>> SMP-built kernels is still supported.
>
> With this patch, I can see the need for the first patch (although
> there's things broken even for that), but is this really a stable fix?
>
> This looks more of an added feature than a bug fix. It's a bug fix if we
> consider running tree_rcu on UP a bug. Or better stated, will it break
> anything if we do that?
>
> -- Steve
>
>>
>> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>
>> commit 8008e129dc90ff4f7a56cb033d6bd042afe3ed52 upstream
>> Cherry-picked for v3.0-rt and fixed-up merge conflicts
>> Note: This makes the depends lines for these options in init/Kconfig for v3.0-rt
>> match those for v3.2-rc2-rt3
>> Signed-off-by: John Kacur <jkacur@redhat.com>
>> ---
>>  init/Kconfig |    6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 89e40a4..5c1147e 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -391,7 +391,7 @@ config TREE_RCU
>>
>>  config TREE_PREEMPT_RCU
>>       bool "Preemptible tree-based hierarchical RCU"
>> -     depends on PREEMPT
>> +     depends on PREEMPT && SMP
>>       help
>>         This option selects the RCU implementation that is
>>         designed for very large SMP systems with hundreds or
>> @@ -401,7 +401,7 @@ config TREE_PREEMPT_RCU
>>
>>  config TINY_RCU
>>       bool "UP-only small-memory-footprint RCU"
>> -     depends on !SMP && !PREEMPT_RT_FULL
>> +     depends on !PREEMPT && !SMP
>>       help
>>         This option selects the RCU implementation that is
>>         designed for UP systems from which real-time response
>> @@ -410,7 +410,7 @@ config TINY_RCU
>>
>>  config TINY_PREEMPT_RCU
>>       bool "Preemptible UP-only small-memory-footprint RCU"
>> -     depends on !SMP && PREEMPT && !PREEMPT_RT_FULL
>> +     depends on PREEMPT && !SMP
>>       help
>>         This option selects the RCU implementation that is designed
>>         for real-time UP systems.  This option greatly reduces the
>

Imagine you have a uni-processor system and want to do real-time.
According to the descriptions in init/Kconfig, you would want to
select TINY_PREEMPT_RCU. The description is

	  This option selects the RCU implementation that is designed
	  for real-time UP systems.  This option greatly reduces the
	  memory footprint of RCU.

Without this patch, you cannot choose this option because of the &&
!PREEMPT_RT_FULL
So, that is a bug, and makes this patch appropriate for stable.

I suppose if you want to be really conservative, you can say we only
need that third hunk.
However, this upstream patch, makes these options in v3.0-rt match the
options in v3.2-rc2-rt3.

Furthermore, it doesn't seem like a good idea to me to support
configurations in a stable branch that are not supported upstream.

Thanks

John
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] rcu: Drive configuration directly from SMP and PREEMPT

[Steven Rostedt]

On Tue, 2011-11-22 at 00:18 +0100, John Kacur wrote:

> Imagine you have a uni-processor system and want to do real-time.
> According to the descriptions in init/Kconfig, you would want to
> select TINY_PREEMPT_RCU. The description is
> 
> 	  This option selects the RCU implementation that is designed
> 	  for real-time UP systems.  This option greatly reduces the
> 	  memory footprint of RCU.
> 
> Without this patch, you cannot choose this option because of the &&
> !PREEMPT_RT_FULL
> So, that is a bug, and makes this patch appropriate for stable.


3.0-rt never supported rcutiny, which means adding it now is not a bug
fix but a new feature. Sure, it may have been a mistake that Thomas kept
rcutiny out for 3.0-rt, but because 3.0-rt never supported it, and
3.0-rt can fully support rcutree with !SMP, there is no bug to be fixed
here. You're adding a new feature to stable, not fixing someones
problem.

> 
> I suppose if you want to be really conservative, you can say we only
> need that third hunk.
> However, this upstream patch, makes these options in v3.0-rt match the
> options in v3.2-rc2-rt3.
> 
> Furthermore, it doesn't seem like a good idea to me to support
> configurations in a stable branch that are not supported upstream.

No, upstream changed the game, in which the configuration can't be
supported. But the stable release can fully support this configuration.
there's no reason to this change just because the latest tree can't
support it. It's like we have to deprecate everything in stable that has
been deprecated in upstream.

Stable is not a mirror of upstream, it's a snapshot in time. Only if we
discover something that crashes, or causes huge latencies do we want to
update stable. Not when we realized that a feature wasn't supported by
-rt.

-- Steve

Re: [PATCH 3/3] rcu: Drive configuration directly from SMP and PREEMPT

[John Kacur]

On Tue, Nov 22, 2011 at 12:46 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 2011-11-22 at 00:18 +0100, John Kacur wrote:
>
>> Imagine you have a uni-processor system and want to do real-time.
>> According to the descriptions in init/Kconfig, you would want to
>> select TINY_PREEMPT_RCU. The description is
>>
>>         This option selects the RCU implementation that is designed
>>         for real-time UP systems.  This option greatly reduces the
>>         memory footprint of RCU.
>>
>> Without this patch, you cannot choose this option because of the &&
>> !PREEMPT_RT_FULL
>> So, that is a bug, and makes this patch appropriate for stable.
>
>
> 3.0-rt never supported rcutiny, which means adding it now is not a bug
> fix but a new feature. Sure, it may have been a mistake that Thomas kept
> rcutiny out for 3.0-rt, but because 3.0-rt never supported it, and
> 3.0-rt can fully support rcutree with !SMP, there is no bug to be fixed
> here. You're adding a new feature to stable, not fixing someones
> problem.
>
>>
>> I suppose if you want to be really conservative, you can say we only
>> need that third hunk.
>> However, this upstream patch, makes these options in v3.0-rt match the
>> options in v3.2-rc2-rt3.
>>
>> Furthermore, it doesn't seem like a good idea to me to support
>> configurations in a stable branch that are not supported upstream.
>
> No, upstream changed the game, in which the configuration can't be
> supported. But the stable release can fully support this configuration.
> there's no reason to this change just because the latest tree can't
> support it. It's like we have to deprecate everything in stable that has
> been deprecated in upstream.
>
> Stable is not a mirror of upstream, it's a snapshot in time. Only if we
> discover something that crashes, or causes huge latencies do we want to
> update stable. Not when we realized that a feature wasn't supported by
> -rt.
>

Okay, I get that and I agree with you - will try to be more careful
about that in the future. However, in this particular case, I don't
think there is a viable rcu choice for UP real-time. Perhaps we can
revisit this again in the future if anyone cares about it.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html