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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux