Faster resume probing
aleksander at aleksander.es
Wed Jan 6 08:24:24 UTC 2021
> Thanks to the logs of ModemManager, I could identify several places
> where we lose some time during the resume sequence of a suspend/resume
> 1. ModemManager waits a fixed amount of time to make sure that all
> ports of a modem show up using udev, losing ~1.5s
It's a bit more complex than that; but yes, at least 1.5s waiting is
the minimum IIRC. This is because there are systems where the ports
are notified slower (e.g. openwrt using mmcli --report-kernel-event is
slower than a standard distro using udev). The refactoring done in
this area in the past years has always been to try to increase that
minimum time, never to reduce it, basically because we rely on how
fast we're notified of the ports of a given modem.
> 2. The EG25-G modem contains ~20 carrier configs which are read one-by-
> one by ModemManager during the initialization phase which takes ~1.5s
This could be probably improved. There carrier config loading and
checking is required in some modules where we support automatic
carrier config selection, but it's optional in all the others. It may
be possible to reduce this time when the feature is not required.
> 3. Order of service initialization: the voice interface for handling
> calls is initialized at the very end, while location, time, etc. are
> initialized first. ~500ms
This one is tricky, because ideally we would completely ignore all
indications received, of every interface, until the whole
initialization has finished (so it wouldn't matter in which order it's
initialized). Also, the voice interface indication handlers are
enabled during initialization basically for emergency calls, as the
PIN may be locked at that time. For the case of no SIM-PIN lock, your
numbers are probably fine, but you'd need to consider also the
enabling phase, not just the initialization phase.
> 4. Many other small things, each saving several 100ms.
> In total, it takes ~6.5s from waking up until the incoming call is
> announced on DBus.
> The resume sequence can probably be optimized in other places as well,
> but my knowledge of the ModemManager code is rather limited. Because of
> this, I would like to have some input from everyone on this mailing
> list about this problem. All suggestions are welcome!
I think we're probably looking at this issue from the wrong angle.
Instead of improving the device probing and initialization, which is
done on device detection and (currently) also after suspend-resuming;
we should probably avoid triggering the full device re-probe on
resume. The device reprobe on resume was setup in order to cope with
devices that would get power-cycled during the sequence, or that would
at least lose all the state during the suspend-resume (e.g. they would
also be suspended). In your case, and in others (see
the modem stays fully awake and operational while the host is
Also, please take into account that you're analyzing one single device
probing sequence with one single device, and looking at the timing in
that single use case. There are lots of other modules which will
behave differently, and some of them even have much longer probing
times by default (e.g. even up to 30s and more in some cases...). From
the very beginning, the work we've been doing in MM has been to try to
support as many devices as possible, adding quirks where necessary,
not much looking at the actual probing time really. Nowadays, the
timing requirements like yours are much more important, as MM is being
used in many more different platforms with different requirements.
E.g. the timing required in a phone with one single fully known device
type is totally different to the timing required in a PC which may
accept multiple different USB modem dongles (and the latter has been
the single and main usecase of MM for a very long time). So, maybe
it's time to allow some kind of user configuration in the MM daemon;
e.g. to configure timings or to configure behaviors. At the end, all
the new usecases we're seeing are of users integrating MM in very
known and controlled environments where the modem/s in use is/are
totally known from the very beginning.
I think your analysis deserves a much deeper review of what we do
right now and what we should allow doing in the future. The usecases
have changed, and we've tried to adapt MM to the new ones found, but
we're now probably "adding too much by default". Maybe it's really
time to have a config file, but I don't want to open Pandora's box yet
until we can agree on what should be configurable; basically because
adding configurability will also increase the work to maintain all
that, so it should only be done if truly required I think.
What do you think of all this?
More information about the ModemManager-devel