optimus-manager service takes at least 30 seconds to starts at boot

[goliwok]

Describe the bug

When I boot on my machine, I have a "start job is running for optimus manager commands deamon", which block me for something like 30 sec or 1 min. Is it normal ? maybe reducing the waiting time for the service could be a short term fix ..

here it is some commands output:

systemd-analyze critical-chain:

graphical.target @46.072s
└─lightdm.service @45.864s +207ms
  └─optimus-manager.service @12.238s +33.623s
     ....
└─lvm2-monitor.service @2.449s +7.731s

systemd-analyze blame:

         33.623s optimus-manager.service
          7.731s lvm2-monitor.service

lvm2 is also really slow ...

System info

• distribution: 5.2.8-1-MANJARO
• desktop manager: deepin
• display manager: lightdm
• laptop model: razer blade 15 base model 2018

outputLogOptimus.log

[Askannz]

Try with this configuration :

[optimus]
switching=none
pci_power_control=no

(note that this isn't a proper solution, it will reduce the battery life even if it works. It's just so that we can pinpoint the issue).

[goliwok]

the config file path is "/etc/optimus-manager/optimus-manager.conf", right ? Because it didn't change anything ... the config file looks like this now:

[intel]
DRI=3
accel=
driver=modesetting
modeset=yes
tearfree=

[nvidia]
DPI=96
PAT=yes
modeset=yes
options=overclocking

[optimus]
switching=none
pci_power_control=no

no weird stuff inside ? I searched errors from optimus-manager, but I didn't find any logs with timeout errors or any other error from a pending job...

EDIT

Here is the log file updated with the conf above output.log

[Askannz]

Sorry for the late reply, but does this bug still happen with the latest version of optimus-manager ?

[goliwok]

Sorry for the late reply, but does this bug still happen with the latest version of optimus-manager ?

Yes, Nothing changes...

[sebirdman]

I came looking for a solution as well, however it looks like i'm not having nearly as big of an issue:

optimus-manager.service @1.062s +1.941s

Running the latest (1.2.2 from AUR)

[lrprawira]

Looking for solution as well: optimus-manager.service @1min 2.220s +40.178s Optimus Manager (Client) version 1.2.2 from AUR

[chabad360]

I'm getting 4.507s optimus-manager.service from systemd-analyze blame, so it would be nice to have some speed ups. Is it possible python is a bottleneck? Or is it likely something else?

[Askannz]

On my machine: 3.285s optimus-manager.service

So 4.507 sounds about right, depending on your hardware. The delay could come from Python itself, or the loading of kernel modules.

Over 30s is really weird though, definitely something wrong going on. I'm working on improving the logging so that we can see how long each step how the startup process takes.

[Mallchad]

I don't know about that. 3.036 econds is a long time when your whole userspace boot is just 4.448 seconds and your entire boot is 15.614 seonds. I'd definatly like to see this proved. Considering that most people one startup mode would be preferred over another it would be nice to see some kind of option that reduces work performed during boot and waits until post-boot, or if it's possible some kind of lazy loading based on kernel paramaters. EDIT: After thinking about a bit I thought maybe the extra time could be because of python, not the language itself or any inherant slowness but rather because python is loaded post boot since it is not included in any initramfs or baked into the kernel.

[Mallchad]

Well, after careful consideration I think I've found a kind of solution, there is just one more thing to figure out. Essentially, optimus-manager.service does not nee to be availible at boot time, UNLESS the mode is being changed from what was previouslly requested, this is the last problem. I think something alone the lines of a small script or service, that determines whether or not a start-up boot paramater is requested and it is different to the original. Aside from that the loading of optimus-manager.service could easilly be deferred until the graphical target has been reached so that it does not interfere with boot time, all that is required is that the Xorg rule is not removed after shutdown. Alternatively, optimus-manager could encorage doing mode-setting during a session, rather than at boot time. I'm not sure how feasible any of this but I think it's definatly possible to achieve lower boot time without completely compromising the experience.

[chabad360]

From what I've seen, Optimus manager is necessary to load in the Nvidia modules, so it can't just be disabled. However, it also tries to unload said modules first, which might contribute to slowing (this also causes a conflict with foldingathome, which requires the Nvidia module). Right now my solution is just to stick with hybrid mode, and disable Optimus manager.

[Mallchad]

@chabad360 I've done a little tinkering and it appears that optimums-manager is responsible for unloading modules in the first place, as well as removing xorg conf rules. This also seems to occur on on reboot/when the service is stopped. So, I believe, as long as you do not want to boot directly to integrated graphics then there should be no need to immediately load optimus-manager, and thus loading can be deferred till some time after boot. This all leads me to believe that optimus-manager is performing redundant work at boot 9 times out of 10. All it should need to do is quickly make a check what the last boot mode was and only make changes if necessary. In some cases it might be necessary to load 1 or 2 modules to get stuff like reverse PRIME working, but I've found this can easily be baked into the initramfs with minimal effort. Which lead me to the realization that for me, optimus-manager is completely redundant, UNTIL I want to make a switch, otherwise it's just bloating startup for no reason. Either way 3 seconds is too much for doing nothing, and if it is indeed 40 seconds for some that's obscene.

[OctarineSourcerer]

Consistently around 7 seconds for me. Definitely something strange going on.

[whenov]

systemd-analyze critical-chain result on my machine: optimus-manager.service @846ms +5.966s

[alescdb]

9s for me, but #394 reduced it to 2s

[nwildner]

Hello @goliwok , since you are the original reporter here, can you confirm that you are still interested in this issue or, confirm that #394 fixed this to you as well? I'll let this case opened and close it if no answer is provided. Cheers.