Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

27 views
Skip to first unread message

Paul E. McKenney

unread,
Apr 28, 2017, 5:20:05 PM4/28/17
to
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.

Thanx, Paul

------------------------------------------------------------------------

commit e01ef0529ed548c1b30206058c2b5eecbbc07998
Author: Paul E. McKenney <pau...@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 <pau...@linux.vnet.ibm.com>
Cc: Nicolas Pitre <nicola...@linaro.org>

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

Nicolas Pitre

unread,
Apr 28, 2017, 6:00:04 PM4/28/17
to
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.

>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit e01ef0529ed548c1b30206058c2b5eecbbc07998
> Author: Paul E. McKenney <pau...@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 <pau...@linux.vnet.ibm.com>
> Cc: Nicolas Pitre <nicola...@linaro.org>

Acked-by: Nicolas Pitre <ni...@linaro.org>

Paul E. McKenney

unread,
Apr 28, 2017, 8:20:05 PM4/28/17
to
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! ;-)

> > ------------------------------------------------------------------------
> >
> > commit e01ef0529ed548c1b30206058c2b5eecbbc07998
> > Author: Paul E. McKenney <pau...@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 <pau...@linux.vnet.ibm.com>
> > Cc: Nicolas Pitre <nicola...@linaro.org>
>
> Acked-by: Nicolas Pitre <ni...@linaro.org>

Applied, thank you!

Thanx, Paul

Paul E. McKenney

unread,
May 12, 2017, 2:50:06 PM5/12/17
to
On Fri, May 12, 2017 at 11:41:55AM -0700, 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?

And adding Josh Triplett on CC, who I should have CCed to start with.

Thanx, Paul

Paul E. McKenney

unread,
May 12, 2017, 2:50:06 PM5/12/17
to
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

Nicolas Pitre

unread,
May 12, 2017, 3:10:06 PM5/12/17
to
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

Paul E. McKenney

unread,
May 12, 2017, 3:20:06 PM5/12/17
to
OK, then wish me luck. ;-)

Thanx, Paul

Paul E. McKenney

unread,
Jun 3, 2017, 12:00:09 AM6/3/17
to
On Fri, May 12, 2017 at 12:10:05PM -0700, Paul E. McKenney wrote:
> On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote:
> > On Fri, 12 May 2017, Paul E. McKenney wrote:

[ . . . ]

> > 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. ;-)

And still quite a bit of back and forth. How are things with tty?

One question that came up -- what sort of SoCs are you targeting?
A number of people are insisting that smartphone SoCs with 256M DRAM
are the minimal systems of the future. This seems unlikely to me,
given the potential for extremely cheap SoCs with EDRAM or some such,
but figured I should ask what you are targeting.

Thanx, Paul

Nicolas Pitre

unread,
Jun 3, 2017, 1:20:05 AM6/3/17
to
I'm targetting 256 *kilobytes* of RAM. Most likely SRAM. That's not for
smart phones but really cheap IoT devices. That's the next area for
(trimmed down) Linux to conquer. Example targets are STM32 chips.

Please see the following for the rationale and how to get there:

https://lwn.net/Articles/721074/

http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr


Nicolas

Paul E. McKenney

unread,
Jun 3, 2017, 4:40:06 PM6/3/17
to
Ah, thank you for the reminder. I did read that article, but somehow
got a few megabytes stuck in my head instead of the correct quarter meg.

Anyway, don't look now, but Tiny {S,}RCU just might live on, for a bit
longer, anyway.

Thanx, Paul
0 new messages