Re: [Qemu-devel] [PATCH RESEND for 2.3 4/6] xbzrle: check 8 bytes at a time after an concurrency scene

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Amit Shah (amit.shah@redhat.com) wrote:
> On (Wed) 10 Dec 2014 [11:55:49], ChenLiang wrote:
> > On 2014/12/10 11:18, Amit Shah wrote:
> > 
> > > On (Mon) 24 Nov 2014 [19:55:50], arei.gonglei@huawei.com wrote:
> > >> From: ChenLiang <chenliang88@huawei.com>
> > >>
> > >> The logic of old code is correct. But Checking byte by byte will
> > >> consume time after an concurrency scene.
> > >>
> > >> Signed-off-by: ChenLiang <chenliang88@huawei.com>
> > >> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
> > >> ---
> > >>  xbzrle.c | 28 ++++++++++++++++++----------
> > >>  1 file changed, 18 insertions(+), 10 deletions(-)
> > >>
> > >> diff --git a/xbzrle.c b/xbzrle.c
> > >> index d27a140..0477367 100644
> > >> --- a/xbzrle.c
> > >> +++ b/xbzrle.c
> > >> @@ -50,16 +50,24 @@ int xbzrle_encode_buffer(uint8_t *old_buf, uint8_t *new_buf, int slen,
> > >>  
> > >>          /* word at a time for speed */
> > >>          if (!res) {
> > >> -            while (i < slen &&
> > >> -                   (*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
> > >> -                i += sizeof(long);
> > >> -                zrun_len += sizeof(long);
> > >> -            }
> > >> -
> > >> -            /* go over the rest */
> > >> -            while (i < slen && old_buf[i] == new_buf[i]) {
> > >> -                zrun_len++;
> > >> -                i++;
> > >> +            while (i < slen) {
> > >> +                if ((*(long *)(old_buf + i)) == (*(long *)(new_buf + i))) {
> > >> +                    i += sizeof(long);
> > >> +                    zrun_len += sizeof(long);
> > >> +                } else {
> > >> +                    /* go over the rest */
> > >> +                    for (j = 0; j < sizeof(long); j++) {
> > >> +                        if (old_buf[i] == new_buf[i]) {
> > >> +                            i++;
> > >> +                            zrun_len++;
> > > 
> > > I don't see how this is different from the code it's replacing.  The
> > > check and increments are all the same.  Difficult to see why there'll
> > > be a speed benefit.  Can you please explain?  Do you have any
> > > performance numbers for before/after?
> > > 
> > > Thanks,
> > > 
> > > 		Amit
> > > 
> > > .
> > > 
> > 
> > Hi Amit:
> > 
> > +                    for (j = 0; j < sizeof(long); j++) {
> > +                        if (old_buf[i] == new_buf[i]) {
> > +                            i++;
> > +                            zrun_len++;
> > +                        } else {
> > +                            break;
> > +                        }
> > +                    }
> > +                    if (j != sizeof(long)) {
> > +                        break;
> > +                    }
> > 
> > The branch of *j != sizeof(long)* may not be hit after an concurrency scene.
> > so we can continue doing "(*(long *)(old_buf + i)) == (*(long *)(new_buf + i))".
> > On the another side the old code does "old_buf[i] == new_buf[i]".
> 
> Frankly, I still don't see it.
> 
> Earlier:
> 
>  while..
>   match words
>  while..
>   match bytes
> 
> Now:
> 
>   while..
>    match words
>    if word mismatch
>    match bytes
> 
> to me, essentially looks the same.
> 
> I'll propose to drop this patch till we have a proper justification.

Watch for the next patch; - patch 5 makes new_buf be the live, volatile memory,
when that happens you could end up falling into the 'match bytes' and getting
a whole word matching again because it had changed while you were processing it,
and that's the change this loop does, it would flip back to processing
whole words at a time again instead of getting stuck in the byte loop.
(It would be rare I guess)

Dave

> 
> 
> 		Amit
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK