[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe.
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [RfC PATCH 0/4] make display updates thread safe. |
Date: |
Mon, 03 Apr 2017 14:42:15 +0200 |
On Mo, 2017-04-03 at 13:24 +0100, Mark Cave-Ayland wrote:
> On 03/04/17 13:03, Gerd Hoffmann wrote:
>
> > Hi,
> >
> >> I checked the branch, is bitmap_copy_and_clear_atomic correct when you
> >> have partial updates? Maybe you need to handle partial updates of the
> >> first and last word?
> >
> > Should not be a problem. We might clear some more bits, but these are
> > outsize the visible area so they should cause visible corruption (and if
> > the visible area changes the display code needs to do a full refresh
> > anyway).
>
> Right. Also is there a reason that
> cpu_physical_memory_snapshot_and_clear_dirty() uses BITS_PER_LEVEL when
> calculating the alignment used for the first/last addresses?
The code copy doesn't operate on bits but on bitmap longs, so I can just
copy the whole long instead of fiddeling with bits. So I round down to
a bitmap long start. On 64bit hosts that are units of 64 pages.
Actually querying the copied bitmap operates on page granularity of
course.
> Otherwise you end up expanding the range of your last address
> considerably beyond the next page alignment.
Yes, it's larger, but as it expands to the start of the long word I
expect the penalty is almost zero (same cache line) and being able to
just copy the whole long instead of dealing with individual bits should
be a win.
> And also in the main page
> loop why is BITS_PER_LEVEL used? I see that several of the internal
> bitmap routines appear to use BITS_PER_LONG for compressing into the
> bitmap which might be more appropriate?
shift by BITS_PER_LEVEL is the same as division by BITS_PER_LONG
cheers,
Gerd