On Thu, Aug 22, 2019 at 11:06 AM Bjørn Mork <bj...@mork.no> wrote: > > Dan Williams <d...@redhat.com> writes: > > On Wed, 2019-08-21 at 12:23 +0000, Amol Lad wrote: > >> Please help with this. What could be the cause of significant MM > >> startup delay? > > > > When started, or when a new modem is plugged attached, ModemManager > > runs through a hardware detection sequence to figure out whether the > > thing you attached is actually a modem and what ports it has and what > > protocols those ports speak. > > Not prepared to write the code, so I should probably not make > suggestions... But do anyway ;-) > > How about caching protocol probe results and skipping the full probe if > a match is found? > > Keying the cached data and knowing when to ignore the cache is probably > the hard part. But I believe there is a lot to gain for normal use > cases. Most people don't use lots of modems. Many systems will have > the same modem connected to the same port for extended periods. Some > system designs cause the MM probing to run very often, "always" > returning the same result. Looking at my laptop for example: It turns > off power to the internal wwan slot on suspend. So MM must probe the > modem on every resume, causing a significant delay from the system > appears to be up until the network is up again. > > The protocol probes are obviously a waste of time in this case. Unless I > am messing with drivers or descriptors :-) But that's easy to detect. > You could just ignore the protocol cache if any of the udev data > changed. It would still be a large win for most cases. >
I like this idea very much! I've opened a new issue to track this: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/142 -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
