This is a silly but useful distribution check with log10 of the allocation
sizes:
Fast:
108 3
1293 4
12133 5
113330 6
27794 7
1119 8
Slow:
194 3
1738 4
17375 5
143411 6
55 7
3 8
I got no warnings about missed calls, but always be aware that some
numbers might be off - ususally they are ok for relative comparisons.
So yeah, the slow case just needs to map more smaller pieces as that is all it
can find.
That explains the "getting worse with system runtime", and I don#t think there
is much that can be done here.
I'll discuss if there is any gain in splitting this from one thread into
many (for very huge memory sizes).
P.S. Finally I just want to re-iterate that using hugepages due to their
pre-allocation, less fragmentation, less mapping behavior really is the
"config" way out of this.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1838575
Title:
passthrough devices cause >17min boot delay
Status in linux package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Incomplete
Bug description:
Adding passthrough devices to a guest introduces a boot delay of > 17
minutes. During this time libvirt reports the guest to be "paused".
The delay does not seem to scale with the # of hostdevs - that is, 1
hostdev causes about a 17min delay, while 16 only bumps that up to
~18min. Removing all hostdevs avoids the delay.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838575/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
