[systemd-devel] Improving module loading

[Alison Chaiken]

Marko Hoyer:
>> Are you talking about "Save To RAM", "Save to Disk", or a hybrid combination of both?  Or do you have something
>> completely different in mind?

GKH:
>A number of devices in the past have done a "save system image" to flash, and then when starting up, just load the
>system image into memory and jump into it, everything up and running with no "startup time" needed other than the
>initial memory load.

Not all processors currently support this behavior.   See Russ Dill's
talk at 2013 ELC,

"Extending the swsusp Hibernation Framework to ARM,"
http://elinux.org/images/0/0c/Slides.pdf

or, put differently, on x86 3.16,
$# cat /sys/power/state
freeze standby mem disk

On Cortex-A9 3.14:
$# cat /sys/power/state
freeze mem

Dill's work added hibernation support for AM33xx.    My understanding
of his presentation is that hibernation is not fully implemented for
other ARM processors.

On another topic that came up in this thread, why does
systemd-udev-settle.service exist?    Doesn't the execution of this
service imply a synchronization point, and doesn't systemd create
targets rather than services for this purpose?   Wouldn't
systemd-udev-settle.target make more sense then?

Tom Gundersen:
>>>In a stock Fedora/Arch (and probably others, but didn't check)
>>>systemd-modules-load is not used at all.
[ . . . ]
>>>I'm not aware of any kernel modules that legitimately needs to be
>>>loaded in this way (i.e., all the ones that do can/should be fixed).

On my Debian Testing system, I see fuse, loop, lp, ppdev and
parport_pc.   The last 3 are related to printing, and presumably must
be preloaded because some printers will not usefully identify
themselves when powered on.   Giving unsophisticated users access to a
wide variety of hotplugged devices is undoubtedly the main reasons
distros want to use systemd-modules-load.

Marko Hoyer:
>We are not using systemd-modules-load for applying this approach since it is trying to load all modules in one shot.

Can systemd units list kernel modules as explicit dependencies?   If
so, systemd's usual methods for ordering the start of units can
influence the loading order of modules.

Marko Hoyer:
>        - we have heavy graphics drivers (~800kb, stripped), they are needed half the way at startup
>        - video processing unit drivers (don't know the size), they are needed half the way at startup
>        - wireless & bluetooth, they are needed very late
>        - usb subsystem, conventionally needed very late (but this finally depends on the concrete product)
>        - hot plug mass storage handling, conventionally needed very late (but this finally depends on the concrete product)
>        - audio driver, in most of our products needed very late
>        - some drivers for INC communication (partly needed very early -> we compiled in them, partly needed later -> we have them as module)

Consider that wireless, bluetooth, audio and hotplug mass storage have
the modules on which they rely as systemd Requisites in their unit
files.   We put the units for theseservices into a connectivity.target
that comes After a render.target that the graphics, video and INC are
in.   render.target then has as Requisites the GPU, VPU and INC
modules.   When each of these targets is started, the units could
insmod the modules and just skip udev rules altogether.   These
dependencies won't prevent the kernel from trying to load the later
modules sooner, but insmod'ing earlier needed modules explicitly will
still influence the order.

-- Alison Chaiken,
Mentor Graphics

-- 
Alison Chaiken                           alison at she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman