GNOME Bugzilla – Bug 686202
Getting to "source selection" page is too slow
Last modified: 2016-03-31 14:02:55 UTC
Especially when coming back from the preparation stage.
How slow it is and how many ISO images does it list? I've just tried it here and it's not noticeably slower than the "source selection" -> "welcome" screen which is fast.
(In reply to comment #1) > How slow it is and how many ISO images does it list? a good 20-30 seconds of hard drive churning, with a depressed button pushed down, and no ISO images listed. > I've just tried it here > and it's not noticeably slower than the "source selection" -> "welcome" screen > which is fast.
(In reply to comment #2) > (In reply to comment #1) > > How slow it is and how many ISO images does it list? > > a good 20-30 seconds of hard drive churning, with a depressed button pushed > down, and no ISO images listed. Thats terrible but I can't reproduce this either. Have you checked if its gnome-boxes process that is churning hard drive? Shot in the dark about possible causes: Could it be that you have done something to tracker on your system (e.g disabled it)?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > How slow it is and how many ISO images does it list? > > > > a good 20-30 seconds of hard drive churning, with a depressed button pushed > > down, and no ISO images listed. > > Thats terrible but I can't reproduce this either. Have you checked if its > gnome-boxes process that is churning hard drive? Shot in the dark about > possible causes: Could it be that you have done something to tracker on your > system (e.g disabled it)? I didn't change tracker's defaults. I don't know if it was gnome-boxes eating the disk, but it was doing something sync, certainly. Don't do that...
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > How slow it is and how many ISO images does it list? > > > > > > a good 20-30 seconds of hard drive churning, with a depressed button pushed > > > down, and no ISO images listed. > > > > Thats terrible but I can't reproduce this either. Have you checked if its > > gnome-boxes process that is churning hard drive? Shot in the dark about > > possible causes: Could it be that you have done something to tracker on your > > system (e.g disabled it)? > > I didn't change tracker's defaults. I don't know if it was gnome-boxes eating > the disk, but it was doing something sync, certainly. Don't do that... We really do try our best not to make sync blocking calls, especially ones that need to be made often. Since we are unable to reproduce this, it might take some time to find out the cause.
Try using a debug kernel to reproduce the problem. kernel-3.6.1-1.fc18.x86_64 gnome-boxes-3.6.0-1.fc18.x86_64
+ Trace 231041
(In reply to comment #6) > Try using a debug kernel to reproduce the problem. > > kernel-3.6.1-1.fc18.x86_64 Using the exact same kernel here. Thanks for the stack trace. It should be trivial to wrap the g_udev_enumerator_execute() in an async call but according to davidz, this call really shouldn't block: <zeenix> davidz: seems g_udev_enumerator_execute is a blocking call: https://bugzilla.gnome.org/show_bug.cgi?id=686202#c6 <davidz> zeenix: it shouldn't be, no <davidz> zeenix: it only looks through the udev database which is on tmpfs <zeenix> davidz: i thought so since it doesn't provide an async variant <davidz> zeenix: what makes you think it is sync? <davidz> zeenix: docs also explicitly state "Device information is retrieved from the kernel (through the sysfs filesystem) and the udev daemon (through a tmpfs filesystem) and presented through GUdevDevice objects. This means that no blocking IO ever happens (in both cases, we are essentially just reading data from kernel memory) and as such there are no asynchronous versions of the provided methods."
Created attachment 226585 [details] [review] media-manager: Call GUdev.Enumerator.execute asynchronously
(In reply to comment #8) > Created an attachment (id=226585) [details] [review] > media-manager: Call GUdev.Enumerator.execute asynchronously This should work around this issue if stack trace was pointing to the correct place. But before we consider it: <zeenix> davidz: i can't reproduce the bug on my system, neither can teuf <davidz> zeenix: the place where it hangs is in fgets() on the uevent file in sysfs.... <davidz> the stack trace anyway * teuf would say that his system is not slow enough to observe what hadess is seeing <teuf> and the stack trace is probably hadess randomly pressing ctrl+c during the slowness <davidz> I think so <davidz> either way, I don't think there's anything wrong with libudev <davidz> ask hadess to run sysprof? <davidz> that should give you an idea of what's going on
gudev is blocking, both during startup and when creating a new image: readlink("/sys/class/power_supply/hid--battery", "../../devices/pci0000:00/0000:00"..., 1024) = 118 stat("/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:0A5C:4502.0004/power_supply/hid--battery/uevent", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 open("/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:0A5C:4502.0004/power_supply/hid--battery/uevent", O_RDONLY|O_CLOEXEC) = 21 fstat(21, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1948fb2000 read(21, If udev pokes things that query the kernel, and that the kernel tries to query the hardware... I can reproduce this at will.
(In reply to comment #10) > If udev pokes things that query the kernel, and that the kernel tries to query > the hardware... As I said on IRC, my view is that this is a device driver bug - accessing the uevent file should never block. Accessing one or more sysfs attribute files is allowed to block, that's OK, we never touch any of those by default.
The patch just makes it hang later (in this case, when I click "Select file").
If gudev does anything the can potentially block, it should provide async API but as David explained the call is not expected to block. Whether driver or gudev bug or both, its really nothing Boxes should be fixing.