MIME-Version: 1.0
In-Reply-To: <20170603203620.GL3721@linux.vnet.ibm.com>
References: <20170428211546.GA23590@linux.vnet.ibm.com> <alpine.LFD.2.20.1704281744220.21943@knanqh.ubzr>
 <20170429001040.GH3956@linux.vnet.ibm.com> <20170512184155.GA9482@linux.vnet.ibm.com>
 <alpine.LFD.2.20.1705121444260.3061@knanqh.ubzr> <20170512191005.GE3956@linux.vnet.ibm.com>
 <20170603035915.GA23375@linux.vnet.ibm.com> <alpine.LFD.2.20.1706030102570.17440@knanqh.ubzr>
 <20170603203620.GL3721@linux.vnet.ibm.com>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 16 Jan 2018 22:02:10 +0100
Message-ID: <CAK8P3a1AKdSiansYoztQ1GqOUvL8YPAP8HnSGe_gv+wwHk4f4w@mail.gmail.com>
Subject: Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Josh Triplett <josh@joshtriplett.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org

On Sat, Jun 3, 2017 at 10:36 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> 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:
>>
>> https://lwn.net/Articles/721074/
>>
>> http://www.mail-archive.com/search?l=mid&q=alpine.LFD.2.20.1703241215540.2304%40knanqh.ubzr
>
> 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 https://pastebin.com/TiTWHP8t 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'
  rcu_lock_acquire(&(sp)->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'
  rcu_lock_release(&(sp)->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.

         Arnd