On Mon, Dec 05, 2016 at 09:06:17PM +0100, Christian Borntraeger wrote: > On 12/01/2016 08:26 PM, Stefan Hajnoczi wrote: > > This patch is based on the algorithm for the kvm.ko halt_poll_ns > > parameter in Linux. The initial polling time is zero. > > > > If the event loop is woken up within the maximum polling time it means > > polling could be effective, so grow polling time. > > > > If the event loop is woken up beyond the maximum polling time it means > > polling is not effective, so shrink polling time. > > > > If the event loop makes progress within the current polling time then > > the sweet spot has been reached. > > > > This algorithm adjusts the polling time so it can adapt to variations in > > workloads. The goal is to reach the sweet spot while also recognizing > > when polling would hurt more than help. > > > > Two new trace events, poll_grow and poll_shrink, are added for observing > > polling time adjustment. > > > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > > Not sure way, but I have 4 host ramdisks with the same iothread as guest > virtio-blk. running fio in the guest on one of these disks will poll, as > soon as I have 2 disks in fio I almost always see shrinks (so polling > stays at 0) and almost no grows.
Shrinking occurs when polling + ppoll(2) time exceeds poll-max-ns. What is the value of poll-max-ns and how long is run_poll_handlers_end - run_poll_handlers_begin? I wonder if polling both disks takes longer than poll-max-ns once you have two disks. The "polling" activity includes processing the I/O requests, so I imagine the time extends significantly as more disks have I/O requests ready for processing. Maybe the block_ns timing calculation should exclude processing time to avoid false shrinking? It also strikes me that there's a blind spot to the self-tuning algorithm: imagine virtqueue kick via ppoll(2) + ioeventfd takes N nanoseconds. Detecting new virtqueue buffers via polling takes M nanoseconds. When M <= poll-max-ns < N the algorithm decides there is no point in polling but it would actually be faster to poll. The reason is that the algorithm only looks at block_ns, which is N, not M. This seems difficult to tackle because the algorithm has no way of predicting M unless it randomly tries to poll longer. Stefan
signature.asc
Description: PGP signature
