[lkml]   [2018]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RFC tip/core/rcu] Make SRCU be once again optional
On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney
<> wrote:
> On Sat, Jun 03, 2017 at 01:18:43AM -0400, Nicolas Pitre wrote:
>> On Fri, 2 Jun 2017, Paul E. McKenney wrote:
>> > 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.
>> 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:
> 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.

It took me around 200000 randconfig builds since May, but I eventually
ran into the regression caused by this patch, building an ARM kernel
with the defconfig from as input results
in this build failure:

CC arch/arm/kernel/asm-offsets.s
In file included from ./include/linux/notifier.h:16:0,
from ./include/linux/memory_hotplug.h:7,
from ./include/linux/mmzone.h:775,
from ./include/linux/gfp.h:6,
from ./include/linux/mm.h:10,
from arch/arm/kernel/asm-offsets.c:15:
./include/linux/srcu.h: In function 'srcu_read_lock_held':
./include/linux/srcu.h:99:25: error: 'struct srcu_struct' has no
member named 'dep_map'
return lock_is_held(&sp->dep_map);
./include/linux/srcu.h: In function 'srcu_read_lock':
./include/linux/srcu.h:160:24: error: 'struct srcu_struct' has no
member named 'dep_map'
./include/linux/srcu.h: In function 'srcu_read_unlock':
./include/linux/srcu.h:174:24: error: 'struct srcu_struct' has no
member named 'dep_map'

I think what happened here is that randconfig builds basically never hit the
CONFIG_SRCU=n case since lots of other things 'select SRCU', directly
or indirectly. Until commit c9afbec27089 ("debugfs: purge obsolete SRCU
based removal protection"), SRCU was selected by debugfs, which is
practically always on, now it has become much easier to disable it,
but it's still fairly unlikely.


 \ /
  Last update: 2018-01-16 22:02    [W:0.113 / U:3.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site