linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Chris Webb <chris@arachsys.com>
Cc: balbir@linux.vnet.ibm.com,
	KVM development list <kvm@vger.kernel.org>,
	Rik van Riel <riel@surriel.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [PATCH][RF C/T/D] Unmapped page cache control - via boot parameter
Date: Wed, 17 Mar 2010 18:40:30 +0200	[thread overview]
Message-ID: <4BA105FE.2000607@redhat.com> (raw)
In-Reply-To: <4BA101C5.9040406@redhat.com>

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 reordered by the elevator with respect to one
>> another) rather than three distinct O_DIRECT writes which can't be 
>> permuted?
>> Can qemu issue a write like that? cache=writeback + flush allows this 
>> to be
>> optimised by the block layer in the normal way.
>
>
> Guest side virtio will send this as three requests followed by a 
> flush.  Qemu will issue these as three distinct requests and then 
> flush.  The requests are marked, as Christoph says, in a way that 
> limits their reorderability, and perhaps if we fix these two problems 
> performance will improve.
>
> Something that comes to mind is merging of flush requests.  If N 
> guests issue one write and one flush each, we should issue N writes 
> and just one flush - a flush for the disk applies to all volumes on 
> that disk.
>

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) sees.  Should be a (write, 
flush, write, flush) per pwrite pattern or similar (for writing the data 
and a journal block, perhaps even three writes will be needed).

Then scale this across multiple guests, measure and trace again.  If 
we're lucky, the flushes will be coalesced, if not, we need to work on it.

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-03-17 16:40 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15  7:22 [PATCH][RF C/T/D] Unmapped page cache control - via boot parameter Balbir Singh
2010-03-15  7:48 ` Avi Kivity
2010-03-15  8:07   ` Balbir Singh
2010-03-15  8:27     ` Avi Kivity
2010-03-15  9:17       ` Balbir Singh
2010-03-15  9:27         ` Avi Kivity
2010-03-15 10:45           ` Balbir Singh
2010-03-15 18:48           ` Anthony Liguori
2010-03-16  9:05             ` Avi Kivity
2010-03-19  7:23               ` Dave Hansen
2010-03-15 20:23       ` Chris Webb
2010-03-15 23:43         ` Anthony Liguori
2010-03-16  0:43           ` Christoph Hellwig
2010-03-16  1:27             ` Anthony Liguori
2010-03-16  8:19               ` Christoph Hellwig
2010-03-17 15:14           ` Chris Webb
2010-03-17 15:55             ` Anthony Liguori
2010-03-17 16:27               ` Chris Webb
2010-03-22 21:04                 ` Chris Webb
2010-03-22 21:07                   ` Avi Kivity
2010-03-22 21:10                     ` Chris Webb
2010-03-17 16:27               ` Balbir Singh
2010-03-17 17:05             ` Vivek Goyal
2010-03-17 19:11               ` Chris Webb
2010-03-16  3:16         ` Balbir Singh
2010-03-16  9:17         ` Avi Kivity
2010-03-16  9:54           ` Kevin Wolf
2010-03-16 10:16             ` Avi Kivity
2010-03-16 10:26           ` Christoph Hellwig
2010-03-16 10:36             ` Avi Kivity
2010-03-16 10:44               ` Christoph Hellwig
2010-03-16 11:08                 ` Avi Kivity
2010-03-16 14:27                   ` Balbir Singh
2010-03-16 15:59                     ` Avi Kivity
2010-03-17  8:49                   ` Christoph Hellwig
2010-03-17  9:10                     ` Avi Kivity
2010-03-17 15:24           ` Chris Webb
2010-03-17 16:22             ` Avi Kivity
2010-03-17 16:40               ` Avi Kivity [this message]
2010-03-17 16:47                 ` Chris Webb
2010-03-17 16:53                   ` Avi Kivity
2010-03-17 16:58                     ` Christoph Hellwig
2010-03-17 17:03                       ` Avi Kivity
2010-03-17 16:57                 ` Christoph Hellwig
2010-03-17 17:06                   ` Avi Kivity
2010-03-17 16:52               ` Christoph Hellwig
2010-03-17 17:02                 ` Avi Kivity
2010-03-15 15:46 ` Randy Dunlap
2010-03-16  3:21   ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA105FE.2000607@redhat.com \
    --to=avi@redhat.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=chris@arachsys.com \
    --cc=hch@lst.de \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@surriel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).