Created attachment 911692 [details] Timed trace from dracut --force -L6 Description of problem: I've not studied in depth whats behind it - log is attached, but it looks quite slow to take well over minute task to create dracut ramdisk. It's 2.2 dual core CPU with SSD - yet it's so slow.... Version-Release number of selected component (if applicable): dracut-037-13.git20140402.fc21.x86_64 How reproducible: Steps to Reproduce: 1. dracut --force -L6 2. 3. Actual results: Expected results: Additional info:
Created attachment 911693 [details] /etc/dracut.conf My dracut config file (using hostonly="yes" settings)
with SSD? wow! $ sudo time dracut -f -L 0 9.97user 2.60system 0:09.11elapsed 138%CPU (0avgtext+0avgdata 6168maxresident)k 45832inputs+77624outputs (105major+1716164minor)pagefaults 0swaps also with SSD What's the output of: # dracut --debug -f ?
Created attachment 912033 [details] gzip of: dracut --debug -f
ok, I don't see anomalies. please attach the output of # dracut --profile -f
Created attachment 916471 [details] Gzip of dracut --profile -f As requested profiled dracut.
Hmm, what springs to eye is "/usr/lib/dracut/dracut-functions.sh@114: printf '%s\n' /lib64" occurring 2260 times and ldconfig is being used 2589 times in the profile log.
(In reply to Zdenek Kabelac from comment #5) > Created attachment 916471 [details] > Gzip of dracut --profile -f > > As requested profiled dracut. /usr/lib/dracut/dracut-functions.sh@117 107.334577322 /usr/lib/dracut/dracut-functions.sh@1609 104.55190897 /usr/lib/dracut/dracut-logger.sh@391 49.8261754513 /usr/lib/dracut/dracut-functions.sh@1608 39.3043520451 /usr/lib/dracut/dracut-functions.sh@113 30.0524041653 /usr/lib/dracut/dracut-functions.sh@112 28.9394204617 /usr/lib/dracut/dracut-functions.sh@114 28.5867795944 /usr/lib/dracut/dracut-functions.sh@111 28.5126459599 /bin/dracut@1070 20.1844387054 /bin/dracut@1069 15.0060369968 /bin/dracut@1068 5.48678016663
Should be fixed with: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=c59779cf9337bc0fc48c7a4d8437f7253f6822c3
I've retested with regular rawhide debug kernel: # time dracut -f real 1m25.700s user 0m15.540s sys 1m14.867s then with non-debug kernel # time dracut -f real 0m26.153s user 0m17.965s sys 0m13.694s While I found both cases to be giving too high times - usage of debug kernel cause extreme slowdown for dracut.
Created attachment 993099 [details] New --profile with non-debug rawhide kernel 3.20.0-0.rc0.git7.2.fc23.x86_64
Forget to mention - using these package installed: dracut-tools-041-1.fc22.x86_64 dracut-041-1.fc22.x86_64 dracut-config-rescue-041-1.fc22.x86_64 (So the patch from comment 8 is included)
(In reply to Zdenek Kabelac from comment #9) > I've retested with regular rawhide debug kernel: > > # time dracut -f > real 1m25.700s > user 0m15.540s > sys 1m14.867s > > > then with non-debug kernel > > # time dracut -f > real 0m26.153s > user 0m17.965s > sys 0m13.694s > > > While I found both cases to be giving too high times - usage of debug > kernel cause extreme slowdown for dracut. Debug kernels come with that cost. You'll notice more with applications doing massive syscalls like dracut. Any application doing so will slow down heavily.
(In reply to Zdenek Kabelac from comment #10) > Created attachment 993099 [details] > New --profile with non-debug rawhide kernel 3.20.0-0.rc0.git7.2.fc23.x86_64 /usr/lib/dracut/dracut-functions.sh@1639 79.7587060928 /usr/lib/dracut/dracut-functions.sh@1638 29.5110254288 /usr/lib/dracut/dracut-logger.sh@389 7.61042761803 /bin/dracut@1666 3.62055468559 /bin/dracut@1179 3.23881793022 I have a fix for the first two lines with awk in the pipeline, which shaves half a second in the non-profiling case. No that much, that I consider pulling in a hard dependency on awk for dracut.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.