Hey, > Thanks to the logs of ModemManager, I could identify several places > where we lose some time during the resume sequence of a suspend/resume > cycle: > > 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 https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/31 and especifically https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/31/diffs?commit_id=5d5fc08b0704513c4c6d8f3e18d07476e53757a9), the modem stays fully awake and operational while the host is suspended. 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? -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
