Re: [PATCH 0/14] init: deps: dependency based (parallelized) init

[Alexander Holler]

Am 17.10.2015 um 19:44 schrieb Greg Kroah-Hartman:
> On Sat, Oct 17, 2015 at 07:14:13PM +0200, Alexander Holler wrote:
> > Hello,
> >
> > here is the newest version of my patches to use a dependency based
> > initialization order. It now works without DT too.
> >
> > Background:
> >
> > Currently initcalls are ordered by some levels and the link order. This
> > means whenever a file is renamed, changes directory or a Makefile is
> > modified the order with which initcalls are called might change. This
> > might result in problems. Furthermore, the required dependencies are
> > often not documented, sometimes there are comments in the source or in a
> > commit message, but most often the knowledge why a specific initcall
> > belongs to a specific initcall level isn't obvious without carefully
> > examing he source. And initcalls are used by drivers and subsystems, and
> > the count of both have grown quiet a lot in the last years. So it's
> > rather difficult to maintain a proper link order.
>
> Files move around very rarely, is this really an issue?

No idea. You are maintaining the staging area. ;)

> > Another problem is that the link order can't be modified dynamically at
> > boot time to include dependencies dictated by the hardware. To circumvent
> > this, a brute-force trial-and-error mechanism called deferred probes has
> > been introduced, but this approach, while beeing KISS, has its own
> > problems.
>
> What problems does deferred probing have?  Why not just fix that if
> there is issues with it, as it was supposed to solve this issue without
> needing to annotate anything.

I've not looked why deferred probes are sometimes causing such a large 
delay. But giving that it's brutforce and non-deterministic, some 
drivers might be probed a dozen times, or important drivers might be 
probed very late, forcing all previous probed drivers to be probed again 
(late). Just think at the case the link order is a, b, c but drivers 
have to be called in the order c, b, a.

> > To solve these problems I've written patches to use a topological sort at
> > boot time which uses dependencies to calculate the order with which
> > initcalls are called.
> >
> > Why? What are the benefits (assuming correct dependencies are available)?
> >
> > - It offers a clear in-source documentation for dependencies between
> >    initcalls.
> > - It is robust in regard to file or directory name changes and changes in
> >    a Makefile.
> > - If enabled, the order with which drivers for interfaces are called
> >    (e.g. network interfaces, hard disks), can be defined independent of
> >    the link order. These might result in more stable interface names or
> >    numbers.
> > - If enabled, it makes the the deferred probes obsolete, which might
> >    result in faster boot times.
> > - If enabled, it is possible to call initcalls in parallel. E.g. the
> >    shipped kernel for Fedora 21 (4.1.7-100.fc21.x86_64) contains around
> >    560 initcalls. These are all called in series. Also some of them use
> >    asynchronous stuff by themself, most don't do.
>
> But that shipped kernel boots to X in less than 2 seconds, so there
> isn't really a speed issue here, right?

It's noticeable if your phone, or any other thing you want to use (like 
your route planner, clock or whatever boots in one second instead of two 
when you turn it on.

> > Drawbacks:
> >
> > - It requires a small amount of time to calculate the order a boot time.
> >    But this time is most often smaller than the time saved by using
> >    multiple cores to call initcalls or by not needing deferred probes.
>
> How much time is needed?

I've measured 3ms on a slow ARM box.

> > - Dependencies are required. For everything which can be build as a
> >    module, looking at modules.dep might give some pointers. Looking at
> >    the help from menuconfig also might give some pointers. But in the
> >    end, the most preferable way would be if maintainers or other people
> >    which have a deeper knowledge about the source and functionality
> >    would add the dependencies.
>
> How will a "normal" driver author figure out what those dependancies are
> in order to be able to write them down?  That's my biggest objection

Most drivers are done c&p from an existing driver. And if someone adds 
new code, he should know what these new code is for and on what it depends.

> here, I have no idea how to add these, nor how to properly review such a
> submission.  What about systems that have different ordering/dependancy
> requirements for the same drivers due to different ways the hardware is
> hooked up?  That is not going to work well here, unless I'm missing
> something.

Hmm, how is that solved now?

If you have dependencies dictated by a special HW, this dependencies 
should come in by the HW description.

The deferred probe mechanism exists just since 1 or 2 years. And once 
you had to search the source of non-displayed error in a set of several 
dozens possible sources (because many errors are now non-errors but 
-517) you might learn to hate deferred probes as much as I do. I'm sorry 
for the harsh words in regard to deferred probes.

The way to use dependencies doesn't add new requirements, it just moves 
them away from the link order. Besides that these dependencies are 
making it possible to parallelize the stuff.

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/