From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751062AbeAPVCN (ORCPT + 1 other); Tue, 16 Jan 2018 16:02:13 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:33782 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbeAPVCL (ORCPT ); Tue, 16 Jan 2018 16:02:11 -0500 X-Google-Smtp-Source: ACJfBosb0GtKsivcN2oK5tHRfJmXhNZ17qxZsVx0OvFn3TbVTq3LpP4iJUVuS+avs8WLjfEm/ajZfGdyrueNujRmUEE= MIME-Version: 1.0 In-Reply-To: <20170603203620.GL3721@linux.vnet.ibm.com> References: <20170428211546.GA23590@linux.vnet.ibm.com> <20170429001040.GH3956@linux.vnet.ibm.com> <20170512184155.GA9482@linux.vnet.ibm.com> <20170512191005.GE3956@linux.vnet.ibm.com> <20170603035915.GA23375@linux.vnet.ibm.com> <20170603203620.GL3721@linux.vnet.ibm.com> From: Arnd Bergmann Date: Tue, 16 Jan 2018 22:02:10 +0100 X-Google-Sender-Auth: BReZuZDs9Esc3OgCZ2VPu3h4ERo Message-ID: Subject: Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional To: "Paul E. McKenney" Cc: Nicolas Pitre , Linux Kernel Mailing List , Josh Triplett Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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: >> >> 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