On Tue, Mar 12, 2013 at 09:41:04AM +0100, Peter Lieven wrote:
>
> Am 12.03.2013 um 09:35 schrieb Stefan Hajnoczi :
>
> > On Mon, Mar 11, 2013 at 02:44:03PM +0100, Peter Lieven wrote:
> >> I ever since had a few VMs which are very hard to migrate because of a lot
> >> of memory I/O. I found that
Am 12.03.2013 um 09:35 schrieb Stefan Hajnoczi :
> On Mon, Mar 11, 2013 at 02:44:03PM +0100, Peter Lieven wrote:
>> I ever since had a few VMs which are very hard to migrate because of a lot
>> of memory I/O. I found that finding the next dirty bit
>> seemed to be one of the culprits (apart from
On Mon, Mar 11, 2013 at 02:44:03PM +0100, Peter Lieven wrote:
> I ever since had a few VMs which are very hard to migrate because of a lot of
> memory I/O. I found that finding the next dirty bit
> seemed to be one of the culprits (apart from removing locking which Paolo is
> working on).
>
> I
Am 11.03.2013 18:07, schrieb Paolo Bonzini:
> Il 11/03/2013 18:06, ronnie sahlberg ha scritto:
>> Even more efficient might be to do bitwise instead of logical or
>>
if (tmp | d1 | d2 | d3) {
>> that should remove 3 of the 4 conditional jumps
>> and should become 3 bitwise ors and one c
Il 11/03/2013 18:06, ronnie sahlberg ha scritto:
> Even more efficient might be to do bitwise instead of logical or
>
>> >if (tmp | d1 | d2 | d3) {
> that should remove 3 of the 4 conditional jumps
> and should become 3 bitwise ors and one conditional jump
Without any serious profiling, p
Even more efficient might be to do bitwise instead of logical or
>if (tmp | d1 | d2 | d3) {
that should remove 3 of the 4 conditional jumps
and should become 3 bitwise ors and one conditional jump
On Mon, Mar 11, 2013 at 8:58 AM, Paolo Bonzini wrote:
> Il 11/03/2013 16:37, Peter Lieven
Il 11/03/2013 16:37, Peter Lieven ha scritto:
>
> Am 11.03.2013 um 16:29 schrieb Paolo Bonzini :
>
>> Il 11/03/2013 16:24, Peter Lieven ha scritto:
>>>
How would that be different in your patch? But you can solve it by
making two >= loops, one checking for 4*BITS_PER_LONG and one check
Am 11.03.2013 um 16:42 schrieb Paolo Bonzini :
> Il 11/03/2013 16:41, Peter Lieven ha scritto:
>> can you verify if this does not make difference in the generated object code?
>> in buffer_is_zero() its outside the loop.
>
> No, it doesn't.
ok, i will sent the final patch tomorrow.
one last th
Il 11/03/2013 16:41, Peter Lieven ha scritto:
> can you verify if this does not make difference in the generated object code?
> in buffer_is_zero() its outside the loop.
No, it doesn't.
Paolo
Am 11.03.2013 um 16:37 schrieb Peter Maydell :
> On 11 March 2013 15:24, Peter Lieven wrote:
>> +unsigned long d0,d1,d2,d3;
>
> These commas should have spaces after them. Also, since
> the variables are only used inside the scope of your
> newly added while loop:
>
>> -while (size & ~
On 11 March 2013 15:24, Peter Lieven wrote:
> +unsigned long d0,d1,d2,d3;
These commas should have spaces after them. Also, since
the variables are only used inside the scope of your
newly added while loop:
> -while (size & ~(BITS_PER_LONG-1)) {
> +while (size >= 4*BITS_PER_LONG) {
Am 11.03.2013 um 16:29 schrieb Paolo Bonzini :
> Il 11/03/2013 16:24, Peter Lieven ha scritto:
>>
>>> How would that be different in your patch? But you can solve it by
>>> making two >= loops, one checking for 4*BITS_PER_LONG and one checking
>>> BITS_PER_LONG.
>>
>> This is what I have now:
On 11 March 2013 15:24, Peter Lieven wrote:
> -offset %= BITS_PER_LONG;
> +offset &= (BITS_PER_LONG-1);
Still pointless.
-- PMM
Il 11/03/2013 16:24, Peter Lieven ha scritto:
>
>> How would that be different in your patch? But you can solve it by
>> making two >= loops, one checking for 4*BITS_PER_LONG and one checking
>> BITS_PER_LONG.
>
> This is what I have now:
>
> diff --git a/util/bitops.c b/util/bitops.c
> index e
> How would that be different in your patch? But you can solve it by
> making two >= loops, one checking for 4*BITS_PER_LONG and one checking
> BITS_PER_LONG.
This is what I have now:
diff --git a/util/bitops.c b/util/bitops.c
index e72237a..b0dc93f 100644
--- a/util/bitops.c
+++ b/util/bitops.
Il 11/03/2013 15:22, Peter Lieven ha scritto:
>
> Am 11.03.2013 um 15:14 schrieb Paolo Bonzini :
>
>> Il 11/03/2013 14:44, Peter Lieven ha scritto:
>>> Hi,
>>>
>>> I ever since had a few VMs which are very hard to migrate because of a
>>> lot of memory I/O. I found that finding the next dirty bit
Am 11.03.2013 um 15:22 schrieb Peter Lieven :
>
> Am 11.03.2013 um 15:14 schrieb Paolo Bonzini :
>
>> Il 11/03/2013 14:44, Peter Lieven ha scritto:
>>> Hi,
>>>
>>> I ever since had a few VMs which are very hard to migrate because of a
>>> lot of memory I/O. I found that finding the next dirty
Am 11.03.2013 um 15:14 schrieb Paolo Bonzini :
> Il 11/03/2013 14:44, Peter Lieven ha scritto:
>> Hi,
>>
>> I ever since had a few VMs which are very hard to migrate because of a
>> lot of memory I/O. I found that finding the next dirty bit
>> seemed to be one of the culprits (apart from removin
Il 11/03/2013 14:44, Peter Lieven ha scritto:
> Hi,
>
> I ever since had a few VMs which are very hard to migrate because of a
> lot of memory I/O. I found that finding the next dirty bit
> seemed to be one of the culprits (apart from removing locking which
> Paolo is working on).
>
> I have to f
On 11 March 2013 13:44, Peter Lieven wrote:
> @@ -24,12 +24,13 @@ unsigned long find_next_bit(const unsigned long *addr,
> unsigned long size,
> const unsigned long *p = addr + BITOP_WORD(offset);
> unsigned long result = offset & ~(BITS_PER_LONG-1);
> unsigned long tmp;
> +uns
Hi,
I ever since had a few VMs which are very hard to migrate because of a lot of
memory I/O. I found that finding the next dirty bit
seemed to be one of the culprits (apart from removing locking which Paolo is
working on).
I have to following proposal which seems to help a lot in my case. Jus
21 matches
Mail list logo
