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

From: Greg Kroah-Hartman
Date: Sat Oct 17 2015 - 13:45:03 EST


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?

> 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.

> 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?

> 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?

> - 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
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.

thanks,

greg k-h
--
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/