[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-img convert cache mode for source
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] qemu-img convert cache mode for source |
Date: |
Thu, 27 Feb 2014 17:12:49 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
Am 27.02.2014 12:07, schrieb Kevin Wolf:
> Am 27.02.2014 um 02:10 hat Fam Zheng geschrieben:
>> On Wed, 02/26 16:41, Stefan Hajnoczi wrote:
>>> On Wed, Feb 26, 2014 at 11:14:04AM +0100, Peter Lieven wrote:
>>>> I was wondering if it would be a good idea to set the O_DIRECT mode for
>>>> the source
>>>> files of a qemu-img convert process if the source is a host_device?
>>>>
>>>> Currently the backup of a host device is polluting the page cache.
>> Peter, can you give some more detailed explanation of the issue? An example
>> or
>> benchmark will help a lot. As I understand, one time scanning of a file
>> doesn't
>> promote the page cache to active list, so it probably won't hurt real hot
>> cache
>> at all, and will get replaced very soon.
>>
>> Considering readahead and page cache on metadata, I'm not sure if forcing
>> O_DIRECT is a good idea.
>>
>>> The problem is what to do for image formats. An image file can be
>>> very fragmented so the readahead might not be a win. Does this mean
>>> that for image formats we should tell the kernel access will be
>>> random?
>>>
>>> Furthermore, maybe it's best to do readahead inside QEMU so that even
>>> network protocols (nbd, iscsi, etc) can get good performance. They
>>> act like O_DIRECT is always on.
>> Also, experience with booting a network backed guest can be greatly improved,
>> because sometimes BIOS and bootloader are simple minded and load a kernel or
>> initrd by sending thousands of 1 sector requests with iodepth=1, which means
>> latency of network based IO hurts a lot.
> I think I mentioned it a while ago, but our IDE emulation plays a role
> in this as well. PIO requests are always handled sector by sector, no
> matter how big the request was that we got from the BIOS.
Yes, you have pointed that out before. How complicated is it to fix this?
Peter
>
> Kevin
>
>> Doing readahead in QEMU makes sense for image formats as well, because we
>> know
>> where the next data cluster is better than kernel. But again, we are
>> replicating things from kernel.