Re: [PATCH][RF C/T/D] Unmapped page cache control - via boot parameter
From: Anthony Liguori
Date: Mon Mar 15 2010 - 19:43:19 EST
On 03/15/2010 03:23 PM, Chris Webb wrote:
Avi Kivity<avi@xxxxxxxxxx> writes:
On 03/15/2010 10:07 AM, Balbir Singh wrote:
Yes, it is a virtio call away, but is the cost of paying twice in
terms of memory acceptable?
Usually, it isn't, which is why I recommend cache=off.
Hi Avi. One observation about your recommendation for cache=none:
We run hosts of VMs accessing drives backed by logical volumes carved out
from md RAID1. Each host has 32GB RAM and eight cores, divided between (say)
twenty virtual machines, which pretty much fill the available memory on the
host. Our qemu-kvm is new enough that IDE and SCSI drives with writeback
caching turned on get advertised to the guest as having a write-cache, and
FLUSH gets translated to fsync() by qemu. (Consequently cache=writeback
isn't acting as cache=neverflush like it would have done a year ago. I know
that comparing performance for cache=none against that unsafe behaviour
would be somewhat unfair!)
I knew someone would do this...
This really gets down to your definition of "safe" behaviour. As it
stands, if you suffer a power outage, it may lead to guest corruption.
While we are correct in advertising a write-cache, write-caches are
volatile and should a drive lose power, it could lead to data
corruption. Enterprise disks tend to have battery backed write caches
to prevent this.
In the set up you're emulating, the host is acting as a giant write
cache. Should your host fail, you can get data corruption.
cache=writethrough provides a much stronger data guarantee. Even in the
event of a host failure, data integrity will be preserved.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/