On 9 Oct 2013, at 15:37, Paolo Bonzini wrote: > > I agree. 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. That might be far more frequent. 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). -- Alex Bligh
