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.
Peter
