Re: [Qemu-devel] [PATCH] kvm: flush the dirty log when unregistering a slot

[Avi Kivity <avi@redhat.com>]

On 01/27/2012 08:50 AM, Gerhard Wiesinger wrote:
> On Thu, 26 Jan 2012, Avi Kivity wrote:
>
>> On 01/25/2012 10:15 PM, Gerhard Wiesinger wrote:
>>> On Sun, 15 Jan 2012, Avi Kivity wrote:
>>>
>>>> On 01/15/2012 04:40 PM, Gerhard Wiesinger wrote:
>>>>> On Sun, 15 Jan 2012, Jan Kiszka wrote:
>>>>>
>>>>>> On 2012-01-15 15:17, Avi Kivity wrote:
>>>>>>> Otherwise, the dirty log information is lost in the kernel forever.
>>>>>>>
>>>>>>> Fixes opensuse-12.1 boot screen, which changes the vga windows
>>>>>>> rapidly.
>>>>>>
>>>>>> Confirmed, problems solved here.
>>>>>
>>>>> Problem from:
>>>>> http://permalink.gmane.org/gmane.comp.emulators.qemu/131853
>>>>>
>>>>> Confirmed to be fixed, too. Long awaited patch :-)
>>>>
>>>> Sorry, I forgot about that.  Please ping me if I do that.
>>>>
>>>>>
>>>>> BTW: There is also a major difference in video performance:
>>>>> 1.) With Patch: 1400MB/s (MByte/s)
>>>>> 2.) Without Patch: 6MB/s
>>>>>
>>>>> Any reason for that?
>>>>
>>>> What are you measuring exactly?
>>>
>>> I'm measuring VGA video performance under DOS with own written test
>>> program.
>>>
>>> What's strange, new findings: Measurement doesn't depend on the patch.
>>> Sometimes it is high sometimes low. I think I have to investigate
>>> further.
>>>
>>> Any ideas?
>>
>> What vga mode are you using?  What does the test program do?
>
> DOS Test programs, source and binaries can be found at:
> http://www.wiesinger.com/opensource/qemu/
>

And which one is slower?

> 1.) Measures page A000:0000 with videomode 4F02, see:
> http://www.wiesinger.com/opensource/qemu/memperf.c
>
> 2.) Second test program measures setting and getting video bank, see:
> http://www.wiesinger.com/opensource/qemu/int10per.c
> We already talked about the low performance some time ago and tracked
> it down to kernel <=> userspace switching. But I benchmarked it
> already once and I think there are some optimizations possible (linear
> list search) with mapping functions (e.g. trivial hash function before)

That would be due to srcu, but recent optimizations in srcu should make
is faster than it was initially (though still slow - kvm trades off
memory map update speed for run-time memory access speed).

-- 
error compiling committee.c: too many arguments to function