Hi Peter, On Fri, Apr 19, 2013 at 12:22 AM, Peter Lieven <lieven-li...@dlhnet.de> wrote: > On 15.04.2013 15:08, Anthony Liguori wrote: >> >> Peter Crosthwaite <peter.crosthwa...@xilinx.com> writes: >> >>> Modify Anthony's starvation detection logic to keep the BQL unlocked >>> until the starvation condition goes away. Otherwise the counter has to >>> count up to 1000 for each needed iteration until the busy-wait is >>> lifted. >>> >>> Reset the counter back to zero once glib_pollfds_fill returns with a >>> non-zero timout, (indicating a return to normality). The 1000 iteration >>> wait now only happens once on the transition from normal operation to >>> busy-wait starvation. >>> >>> Anthony's original patch fixed the serial paste bug, but this patch is >>> also needed to restore performance. >>> >>> Signed-off-by: Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> >> I'm going through patches for 1.5 candidates. >> >> I believe the paste performance issue has been resolved now and this >> patch is no longer needed. I can't find a definitive statement on the >> list for that though. > > > I am also hitting a problem that occured first after Anthonys original > patch. > In my testing environment I had 3 vServers that indepently of the load > became > heavily unresponsive after reporting "main-loop: WARNING: I/O thread spun > for 1000 iterations". > Even QMP is not responsing from time to time. But I am not using serial. > From the load statistics > it seems that the vServers is using one complete core busy waiting. > > I haven't seen this before this patch.
Are you referring to my patch or Anthonys patch here? Does this patch introduce a regression (or even a change in behaviour) for you? Regards, Peter > > Peter > >
