Chris Webb ch...@arachsys.com writes:
Okay. What I was driving at in describing these systems as 'already broken'
is that they will already lose data (in this sense) if they're run on bare
metal with normal commodity SATA disks with their 32MB write caches on. That
configuration surely
On 03/22/2010 11:04 PM, Chris Webb wrote:
Chris Webbch...@arachsys.com writes:
Okay. What I was driving at in describing these systems as 'already broken'
is that they will already lose data (in this sense) if they're run on bare
metal with normal commodity SATA disks with their 32MB
Avi Kivity a...@redhat.com writes:
On 03/22/2010 11:04 PM, Chris Webb wrote:
Unless I'm missing something, the risk to guest OSes in this configuration
should therefore be exactly the same as the risk from running on normal
commodity hardware with such drives and no expensive battery-backed
On Tue, 2010-03-16 at 11:05 +0200, Avi Kivity wrote:
Not really. In many cloud environments, there's a set of common
images that are instantiated on each node. Usually this is because
you're running a horizontally scalable application or because you're
supporting an ephemeral storage
On Tue, Mar 16, 2010 at 01:08:28PM +0200, Avi Kivity wrote:
If the batch size is larger than the virtio queue size, or if there are
no flushes at all, then yes the huge write cache gives more opportunity
for reordering. But we're already talking hundreds of requests here.
Yes. And
On 03/17/2010 10:49 AM, Christoph Hellwig wrote:
On Tue, Mar 16, 2010 at 01:08:28PM +0200, Avi Kivity wrote:
If the batch size is larger than the virtio queue size, or if there are
no flushes at all, then yes the huge write cache gives more opportunity
for reordering. But we're already
Anthony Liguori anth...@codemonkey.ws writes:
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
Avi Kivity a...@redhat.com writes:
On 03/15/2010 10:23 PM, Chris Webb wrote:
Wasteful duplication of page cache between guest and host notwithstanding,
turning on cache=writeback is a spectacular performance win for our guests.
Is this with qcow2, raw file, or direct volume access?
This
On 03/17/2010 10:14 AM, Chris Webb wrote:
Anthony Liguorianth...@codemonkey.ws writes:
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
On 03/17/2010 05:24 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com writes:
On 03/15/2010 10:23 PM, Chris Webb wrote:
Wasteful duplication of page cache between guest and host notwithstanding,
turning on cache=writeback is a spectacular performance win for our guests.
Is
* Anthony Liguori anth...@codemonkey.ws [2010-03-17 10:55:47]:
On 03/17/2010 10:14 AM, Chris Webb wrote:
Anthony Liguorianth...@codemonkey.ws writes:
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.
Anthony Liguori anth...@codemonkey.ws writes:
On 03/17/2010 10:14 AM, Chris Webb wrote:
(c) installations that are already broken and lose data with a physical
drive with a write-cache can lose much more in this case because the
write cache is much bigger?
This is the
On 03/17/2010 06:22 PM, Avi Kivity wrote:
Also, if my guest kernel issues (say) three small writes, one at the
start
of the disk, one in the middle, one at the end, and then does a
flush, can
virtio really express this as one non-contiguous O_DIRECT write (the
three
components of which can be
Avi Kivity a...@redhat.com writes:
Chris, can you carry out an experiment? Write a program that
pwrite()s a byte to a file at the same location repeatedly, with the
file opened using O_SYNC. Measure the write rate, and run blktrace
on the host to see what the disk (/dev/sda, not the volume)
On Wed, Mar 17, 2010 at 06:22:29PM +0200, Avi Kivity wrote:
They should be reorderable. Otherwise host filesystems on several
volumes would suffer the same problems.
They are reordable, just not as extremly as the the page cache.
Remember that the request queue really is just a relatively
On 03/17/2010 06:47 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com writes:
Chris, can you carry out an experiment? Write a program that
pwrite()s a byte to a file at the same location repeatedly, with the
file opened using O_SYNC. Measure the write rate, and run blktrace
on the host to
On Wed, Mar 17, 2010 at 06:40:30PM +0200, Avi Kivity wrote:
Chris, can you carry out an experiment? Write a program that pwrite()s
a byte to a file at the same location repeatedly, with the file opened
using O_SYNC. Measure the write rate, and run blktrace on the host to
see what the disk
On Wed, Mar 17, 2010 at 06:53:34PM +0200, Avi Kivity wrote:
Meanwhile I looked at the code, and it looks bad. There is an
IO_CMD_FDSYNC, but it isn't tagged, so we have to drain the queue before
issuing it. In any case, qemu doesn't use it as far as I could tell,
and even if it did,
On 03/17/2010 06:58 PM, Christoph Hellwig wrote:
On Wed, Mar 17, 2010 at 06:53:34PM +0200, Avi Kivity wrote:
Meanwhile I looked at the code, and it looks bad. There is an
IO_CMD_FDSYNC, but it isn't tagged, so we have to drain the queue before
issuing it. In any case, qemu doesn't use it
On 03/17/2010 06:52 PM, Christoph Hellwig wrote:
On Wed, Mar 17, 2010 at 06:22:29PM +0200, Avi Kivity wrote:
They should be reorderable. Otherwise host filesystems on several
volumes would suffer the same problems.
They are reordable, just not as extremly as the the page cache.
On 03/17/2010 06:57 PM, Christoph Hellwig wrote:
On Wed, Mar 17, 2010 at 06:40:30PM +0200, Avi Kivity wrote:
Chris, can you carry out an experiment? Write a program that pwrite()s
a byte to a file at the same location repeatedly, with the file opened
using O_SYNC. Measure the write rate,
On Wed, Mar 17, 2010 at 03:14:10PM +, Chris Webb wrote:
Anthony Liguori anth...@codemonkey.ws writes:
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
Vivek Goyal vgo...@redhat.com writes:
Are you using CFQ in the host? What is the host kernel version? I am not sure
what is the problem here but you might want to play with IO controller and put
these guests in individual cgroups and see if you get better throughput even
with
On Mon, Mar 15, 2010 at 08:27:25PM -0500, Anthony Liguori wrote:
Actually cache=writeback is as safe as any normal host is with a
volatile disk cache, except that in this case the disk cache is
actually a lot larger. With a properly implemented filesystem this
will never cause corruption.
On 03/15/2010 08:48 PM, Anthony Liguori wrote:
On 03/15/2010 04:27 AM, Avi Kivity wrote:
That's only beneficial if the cache is shared. Otherwise, you could
use the balloon to evict cache when memory is tight.
Shared cache is mostly a desktop thing where users run similar
workloads. For
On 03/15/2010 10:23 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com 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.
Am 16.03.2010 10:17, schrieb Avi Kivity:
On 03/15/2010 10:23 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com 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
On 03/16/2010 11:54 AM, Kevin Wolf wrote:
Is this with qcow2, raw file, or direct volume access?
I can understand it for qcow2, but for direct volume access this
shouldn't happen. The guest schedules as many writes as it can,
followed by a sync. The host (and disk) can then reschedule them
Avi,
cache=writeback can be faster than cache=none for the same reasons
a disk cache speeds up access. As long as the I/O mix contains more
asynchronous then synchronous writes it allows the host to do much
more reordering, only limited by the cache size (which can be quite
huge when using the
On 03/16/2010 12:26 PM, Christoph Hellwig wrote:
Avi,
cache=writeback can be faster than cache=none for the same reasons
a disk cache speeds up access. As long as the I/O mix contains more
asynchronous then synchronous writes it allows the host to do much
more reordering, only limited by the
On Tue, Mar 16, 2010 at 12:36:31PM +0200, Avi Kivity wrote:
Are you talking about direct volume access or qcow2?
Doesn't matter.
For direct volume access, I still don't get it. The number of barriers
issues by the host must equal (or exceed, but that's pointless) the
number of barriers
On 03/16/2010 12:44 PM, Christoph Hellwig wrote:
On Tue, Mar 16, 2010 at 12:36:31PM +0200, Avi Kivity wrote:
Are you talking about direct volume access or qcow2?
Doesn't matter.
For direct volume access, I still don't get it. The number of barriers
issues by the host must
* Avi Kivity a...@redhat.com [2010-03-16 13:08:28]:
On 03/16/2010 12:44 PM, Christoph Hellwig wrote:
On Tue, Mar 16, 2010 at 12:36:31PM +0200, Avi Kivity wrote:
Are you talking about direct volume access or qcow2?
Doesn't matter.
For direct volume access, I still don't get it. The number
On 03/16/2010 04:27 PM, Balbir Singh wrote:
Let's assume the guest has virtio (I agree with IDE we need
reordering on the host). The guest sends batches of I/O separated
by cache flushes. If the batches are smaller than the virtio queue
length, ideally things look like:
io_submit(...,
On 03/15/2010 09:22 AM, Balbir Singh wrote:
Selectively control Unmapped Page Cache (nospam version)
From: Balbir Singhbal...@linux.vnet.ibm.com
This patch implements unmapped page cache control via preferred
page cache reclaim. The current patch hooks into kswapd and reclaims
page cache if
* Avi Kivity a...@redhat.com [2010-03-15 09:48:05]:
On 03/15/2010 09:22 AM, Balbir Singh wrote:
Selectively control Unmapped Page Cache (nospam version)
From: Balbir Singhbal...@linux.vnet.ibm.com
This patch implements unmapped page cache control via preferred
page cache reclaim. The
On 03/15/2010 10:07 AM, Balbir Singh wrote:
* Avi Kivitya...@redhat.com [2010-03-15 09:48:05]:
On 03/15/2010 09:22 AM, Balbir Singh wrote:
Selectively control Unmapped Page Cache (nospam version)
From: Balbir Singhbal...@linux.vnet.ibm.com
This patch implements unmapped page
* Avi Kivity a...@redhat.com [2010-03-15 10:27:45]:
On 03/15/2010 10:07 AM, Balbir Singh wrote:
* Avi Kivitya...@redhat.com [2010-03-15 09:48:05]:
On 03/15/2010 09:22 AM, Balbir Singh wrote:
Selectively control Unmapped Page Cache (nospam version)
From: Balbir
On 03/15/2010 11:17 AM, Balbir Singh wrote:
* Avi Kivitya...@redhat.com [2010-03-15 10:27:45]:
On 03/15/2010 10:07 AM, Balbir Singh wrote:
* Avi Kivitya...@redhat.com [2010-03-15 09:48:05]:
On 03/15/2010 09:22 AM, Balbir Singh wrote:
Selectively control
* Avi Kivity a...@redhat.com [2010-03-15 11:27:56]:
The knobs are for
1. Selective enablement
2. Selective control of the % of unmapped pages
An alternative path is to enable KSM for page cache. Then we have
direct read-only guest access to host page cache, without any guest
On Mon, 15 Mar 2010 12:52:15 +0530 Balbir Singh wrote:
Selectively control Unmapped Page Cache (nospam version)
From: Balbir Singh bal...@linux.vnet.ibm.com
This patch implements unmapped page cache control via preferred
page cache reclaim. The current patch hooks into kswapd and reclaims
On 03/15/2010 04:27 AM, Avi Kivity wrote:
That's only beneficial if the cache is shared. Otherwise, you could
use the balloon to evict cache when memory is tight.
Shared cache is mostly a desktop thing where users run similar
workloads. For servers, it's much less likely. So a
Avi Kivity a...@redhat.com 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
On 03/15/2010 03:23 PM, Chris Webb wrote:
Avi Kivitya...@redhat.com 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.
On Mon, Mar 15, 2010 at 06:43:06PM -0500, Anthony Liguori wrote:
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,
On 03/15/2010 07:43 PM, Christoph Hellwig wrote:
On Mon, Mar 15, 2010 at 06:43:06PM -0500, Anthony Liguori wrote:
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
* Chris Webb ch...@arachsys.com [2010-03-15 20:23:54]:
Avi Kivity a...@redhat.com 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
* Randy Dunlap randy.dun...@oracle.com [2010-03-15 08:46:31]:
On Mon, 15 Mar 2010 12:52:15 +0530 Balbir Singh wrote:
Hi,
If you go ahead with this, please add the boot parameter its description
to Documentation/kernel-parameters.txt.
I certainly will, thanks for keeping a watch.
--
48 matches
Mail list logo
