Il 09/10/2013 18:19, Alex Bligh ha scritto: >> Do you also agree that the equivalent workaround, before >> > Alex's patch, was MIN_REARM_TIMER_NS (and thus 250 microseconds)? > I don't think this was the case, as if it's a timer constantly > expiring we'd have seen select() exit as soon as it was entered > by the fd poked by the signal.
The signal itself was clamped to be at least 250 microseconds... > That might be far more frequent. ... it's true though that it could have been less than 250 microseconds (more precisely, 250 microseconds minus the time from qemu_mod_timer_ns to select). Since the CPU usage with Hans's patch is 100% and used to be 50%, it was also more than 1 ns that Hans's patch is using. > I think the equivalent would be something like: if the 'zero' > timeout comes from the deadline calculation (and not > nonblocking=true) then release the lock anyway. I think > that would be a reasonable approach. > > I would however like to get to the bottom of what's causing > this as even pre my changes playing sound was apparently taking > 50% CPU, which is not good. I am completely packed until the > weekend but I propose producing a timer debug patch which > will instrument what is expiring constantly (unless the > problem with spice is obvious to someone). I think Hans already debugged it to the (supposedly) 33 Hz timer that spice audio uses. If it turns out the bug is in the QEMU part of spice, I think it makes sense _not_ to include this patch at all. If it turns out to be in spice itself, then we can include it as a workaround, but still it would be nice to tune a bit the limit and not burn even more CPU time than before. Paolo
