On 12/01/2010 10:25 AM, Juan Quintela wrote:
Anthony Liguori<anth...@codemonkey.ws> wrote:
On 12/01/2010 09:51 AM, Juan Quintela wrote:
Avi Kivity<a...@redhat.com> wrote:
On 11/30/2010 04:46 PM, Juan Quintela wrote:
Anthony Liguori<anth...@codemonkey.ws> wrote:
On 11/23/2010 05:03 PM, Juan Quintela wrote:
From: Juan Quintela<quint...@trasno.org>
Calculate the number of dirty pages takes a lot on hosts with lots
of memory. Just maintain how many pages are dirty. Only sync bitmaps
if number is small enough.
There needs to be numbers that justify this as part of the commit message.
They are on patch 0/6.
Additionally, with 64GB of RAM, this bitmap is HUGE, having to walk over
it in each ram_save_live() call is too onerous.
It's not so huge. It's scaled down by a factor of 8 * 4096 = 32K. So
it's a 2MB bitmap. If kept as a bitmap and accessed in longs, it can
be read in less than a millisecond.
BTW, by this logic, even a 1-byte dirty bitmap is only 16mb which can
be read in less than 16ms so where is the reported 24 minute stall
coming from?
a) we read the bitmap more than once
Not in a single iteration which is what the "stall" would consist of.
b) the 1ms is based on "we read" it with longs and optimized, just now
we have to read it by byte and inside the byte.
Byte accesses verse long access doesn't turn 16ms into 24 minutes.
Regards,
Anthony Liguori
Later, Juan.
Regards,
Anthony Liguori
