On Mon, Jul 31, 2017 at 04:26:08PM +0300, Michael S. Tsirkin wrote: > On Sun, Jul 30, 2017 at 03:25:52PM -0700, Euan Kemp wrote: > > I've also observed this performance regression. > > > > The minimal fix for me is removing the two > > > if (unlikely(len > (unsigned long)ctx)) > > checks added in 680557c. > > > > After digging a little more, the reason that check can fail appears to > > be that add_recvbuf_mergeable sometimes includes a hole at the end, > > which is included in len but not ctx. > > > > I'd send a patch removing those conditions, but I'm not certain > > whether "truesize" in receive_mergeable should also be changed back to > > be the max of len/ctx, or should remain as-is. > > > > - Euan > > Thanks a lot for looking into it! > > I kept this around unchanged from > ab7db91705e95ed1bba1304388936fccfa58c992. That commit had an internal > reason not to account for that space: not enough bits to do it. No > longer true so let's account for length exactly. I'll send a proper > patch after a bit of testing, would appreciate reports reports of > whether this helps very much. > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
This fixes the issue for me, downloads are faster and rx_length_errors does not show any errors. Tested-by: Seth Forshee <seth.fors...@canonical.com> Thanks! Seth
