Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1640687 > unrolled thread

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-12 20:50 +0200
    Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-05-12 21:10 +0200
      Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-12 21:20 +0200

#1640687 — Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote:
> On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote:
> > On Fri, 28 Apr 2017, Paul E. McKenney wrote:
> > 
> > > Hello, Nicolas!
> > > 
> > > Saw the TTY write up LWN and figured I should send this your way.
> > > It should be worth about 2K compared to current -next, which gave
> > > up the 2K compared to v4.10.  So really getting things back to where
> > > they were.
> > > 
> > > My current plan is to push this into v4.13.
> > 
> > Excellent!
> > 
> > If every maintainer finds a way to (optionally) reduce the size of the 
> > code they maintain by 2K then we'll get a much smaller kernel pretty 
> > soon.
> 
> I would feel better if it wasn't me who had added the 2K, but then
> again, I do look forward to seeing a negative-sized kernel!  ;-)

And I am getting a lot of offlist pressure to remove both Tiny RCU and
Tiny SRCU.  I am pushing back, but I might or might not prevail.  In case
my pushback gets pushed back, do you have a -tiny tree or some such where
the code could go?

							Thanx, Paul

> > > ------------------------------------------------------------------------
> > > 
> > > commit e01ef0529ed548c1b30206058c2b5eecbbc07998
> > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > Date:   Fri Apr 28 13:53:04 2017 -0700
> > > 
> > >     srcu: Make SRCU be once again optional
> > >     
> > >     Commit d160a727c40e ("srcu: Make SRCU be built by default") in response
> > >     to build errors, which were caused by code that included srcu.h
> > >     despite !SRCU.  However, srcutiny.o is almost 2K of code, which is not
> > >     insignificant for those attempting to run the Linux kernel on IoT devices.
> > >     This commit therefore makes SRCU be once again optional, and adjusts
> > >     srcu.h to allow error-free inclusion in !SRCU kernel builds.
> > >     
> > >     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > >     Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> Applied, thank you!
> 
> 							Thanx, Paul
> 
> > > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> > > index 167ad8831aaf..c0143fe2e39d 100644
> > > --- a/include/linux/srcu.h
> > > +++ b/include/linux/srcu.h
> > > @@ -62,7 +62,7 @@ int init_srcu_struct(struct srcu_struct *sp);
> > >  #include <linux/srcutree.h>
> > >  #elif defined(CONFIG_CLASSIC_SRCU)
> > >  #include <linux/srcuclassic.h>
> > > -#else
> > > +#elif defined(CONFIG_SRCU)
> > >  #error "Unknown SRCU implementation specified to kernel configuration"
> > >  #endif
> > >  
> > > diff --git a/init/Kconfig b/init/Kconfig
> > > index 42a346b0df43..fe72c12e06a5 100644
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -521,7 +521,6 @@ config RCU_EXPERT
> > >  
> > >  config SRCU
> > >  	bool
> > > -	default y
> > >  	help
> > >  	  This option selects the sleepable version of RCU. This version
> > >  	  permits arbitrary sleeping or blocking within RCU read-side critical
> > > 
> > > 
> > 

[toc] | [next] | [standalone]

#1640700

On Fri, 12 May 2017, Paul E. McKenney wrote:

> On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote:
> > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote:
> > > On Fri, 28 Apr 2017, Paul E. McKenney wrote:
> > > 
> > > > Hello, Nicolas!
> > > > 
> > > > Saw the TTY write up LWN and figured I should send this your way.
> > > > It should be worth about 2K compared to current -next, which gave
> > > > up the 2K compared to v4.10.  So really getting things back to where
> > > > they were.
> > > > 
> > > > My current plan is to push this into v4.13.
> > > 
> > > Excellent!
> > > 
> > > If every maintainer finds a way to (optionally) reduce the size of the 
> > > code they maintain by 2K then we'll get a much smaller kernel pretty 
> > > soon.
> > 
> > I would feel better if it wasn't me who had added the 2K, but then
> > again, I do look forward to seeing a negative-sized kernel!  ;-)
> 
> And I am getting a lot of offlist pressure to remove both Tiny RCU and
> Tiny SRCU.  I am pushing back, but I might or might not prevail.  In case
> my pushback gets pushed back, do you have a -tiny tree or some such where
> the code could go?

No.  "Available in mainline" is the name of the game for all I do. If it 
can't be made acceptable for mainline then it basically has no chance of 
gaining traction and becoming generally useful. My approach is therefore 
to always find solutions that can be maintained upstream and contributed 
to with minimal fuss by anyone.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1640705

On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote:
> On Fri, 12 May 2017, Paul E. McKenney wrote:
> 
> > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote:
> > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote:
> > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote:
> > > > 
> > > > > Hello, Nicolas!
> > > > > 
> > > > > Saw the TTY write up LWN and figured I should send this your way.
> > > > > It should be worth about 2K compared to current -next, which gave
> > > > > up the 2K compared to v4.10.  So really getting things back to where
> > > > > they were.
> > > > > 
> > > > > My current plan is to push this into v4.13.
> > > > 
> > > > Excellent!
> > > > 
> > > > If every maintainer finds a way to (optionally) reduce the size of the 
> > > > code they maintain by 2K then we'll get a much smaller kernel pretty 
> > > > soon.
> > > 
> > > I would feel better if it wasn't me who had added the 2K, but then
> > > again, I do look forward to seeing a negative-sized kernel!  ;-)
> > 
> > And I am getting a lot of offlist pressure to remove both Tiny RCU and
> > Tiny SRCU.  I am pushing back, but I might or might not prevail.  In case
> > my pushback gets pushed back, do you have a -tiny tree or some such where
> > the code could go?
> 
> No.  "Available in mainline" is the name of the game for all I do. If it 
> can't be made acceptable for mainline then it basically has no chance of 
> gaining traction and becoming generally useful. My approach is therefore 
> to always find solutions that can be maintained upstream and contributed 
> to with minimal fuss by anyone.

OK, then wish me luck.  ;-)

							Thanx, Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web