From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Subject: Re: Why is the deferred initcall patch not mainline? Date: Wed, 22 Oct 2014 07:31:18 +0200 Message-ID: <54474126.2070305@de.bosch.com> References: <5441F592.6090807@gmail.com> , Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-embedded-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "Bird, Tim" , Nicolas Pitre , Grant Likely , Borislav Petkov , Geert Uytterhoeven Cc: "linux-embedded@vger.kernel.org" , Dirk Behme , Alexandre Belloni , "tim.bird@am.sony.com" On 21.10.2014 21:37, Bird, Tim wrote: > I'm going to respond to several comments in this one message (sorry for the likely confusion) > > On Tuesday, October 21, 2014 9:31 AM, Nicolas Pitre [nico@fluxnic.net] wrote: >> >> On Tue, 21 Oct 2014, Grant Likely wrote: >> >>> On Sat, Oct 18, 2014 at 9:11 AM, Bird, Tim wrote: >>>> The answer is pretty easy, I think. I tried to mainline it once but failed, and didn't really >>>> try again. If it is being found useful, we should try to mainline it again, this time with >>>> more persistence. The reason it got rejected before IIRC was that you can accomplish >>>> a similar thing with modules, with no changes to the kernel. But that doesn't cover >>>> the case where the loadable modules feature of the kernel is turned off, which is >>>> common in very small systems. >>> >>> It is a rather clumsy approach though since it requires changes to >>> modules and it makes the configuration static per build. Could it >>> instead be done by the kernel accepting a list of initcalls that >>> should be deferred? It would depend I suppose on the cost of finding >>> the initcalls to defer at boot time. > > Yeah, I'm not a big fan of having to change kernel code in order to > use the feature. I am quite intrigued by Geert Uytterhoeven's idea > to add a 'D' option to the config system, so that the record of which > modules to defer could be stored there. This is much better than > hand-altering code. I don't know how difficult this would be to add > to the kbuild system, but the mechanism for altering the macro would > be, IMHO, very straightforward. > > I should say that it's been quite some time since I worked on this, > so some of my recollections may be fuzzy. > > With regards to doing it dynamically, I'd have to think about how > to do that. Having text-based lists of things to do at runtime seems > to fit with how we're using device tree these days, but I'm not sure > how that would work. > > The code as it stands now is quite simple, just creating a new linker section > to hold the list of deferred function pointers, re-using all existing > routines for processing such lists, doing a few code changes to handle > actually deferring the initialization and memory free-ing, and finally > creating a /proc entry to trigger the whole thing. > > In a modern kernel, the /proc trigger should definitely be moved to > /sys. Other than this, though, if you move to some other system of > processing the list, you will have to create new infrastructure for > working through the deferred module list, or make a change in the > way the items are handled in the generic init function pointer processing. > A simple solution would be to just compare each item from each ...initcall.init > section with a list of deferred functions, and not process them, until doing > the deferred init. > > Note that the current technique uses the compiler and linker do some of > the work for list aggregation and processing, so that would have to be replaced > with something else if you do it differently. > >>> >>> I missed the session unfortunately, are there some measurements >>> available that I could look at? Which subsystems are typically the >>> problem? >> >> I, too, would like to know more about the problem. Any pointers? > > Here is the elinux wiki page with some historical measurements: > http://elinux.org/Deferred_Initcalls > > The example on the wiki page defers 2 USB modules, and it > saved 530 milliseconds on an x86 system. > > This is consistent with what we saw on cameras at Sony. > This patch predated Arjan Van de Ven's fastboot work. I don't > know if some of his parallelization (asynchronous module loading), and > optimizations for USB loading made things substantially better than this. > The USB spec makes in impossible to avoid a certain amount of delay > in probing the USB busses > > USB was the main culprit, but we sometimes deferred other modules, if they > were not in the fastpath for taking a picture. Sony cameras had a goal of > booting in .5 seconds, but I think the best we ever achieved was about 1.1 > seconds, using deferred initcalls and a variety of other techniques. To extend the list of usage examples, e.g. -late_initcall(clk_debug_init); +deferred_initcall(clk_debug_init); I.e. you might want to have some debug features enabled, but you don't want to spend the time needed for initializing them in the time critical boot phase. Best regards Dirk