On 01.07.2010, at 09:29, Avi Kivity wrote:
> On 06/30/2010 04:18 PM, Alexander Graf wrote:
>> Book3s suffered from my really bad shadow MMU implementation so far. So
>> I finally got around to implement a combined hash and list mechanism that
>> allows for much faster lookup of mapped pages.
>>
>> To show that it really is faster, I tried to run simple process spawning
>> code inside the guest with and without these patches:
>>
>> [without]
>>
>> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null;
>> done
>>
>> real 0m20.235s
>> user 0m10.418s
>> sys 0m9.766s
>>
>> [with]
>>
>> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null;
>> done
>>
>> real 0m14.659s
>> user 0m8.967s
>> sys 0m5.688s
>>
>> So as you can see, performance improved significantly.
>>
>> v2 -> v3:
>>
>> - use hlist
>> - use global slab cache
>>
>>
>
> Looks good.
Great :).
How does dirty bitmap flushing work on x86 atm? I loop through all mapped pages
and flush the ones that match the range of the region I need to flush. But
wouldn't it be a lot more efficient to have an hlist in the memslot and loop
through that when I need to flush that memslot?
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
