LKML Archive on
help / color / mirror / Atom feed
From: Blaisorblade <>
Cc: Jeff Dike <>, Andrew Morton <>,
	LKML <>
Subject: Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
Date: Fri, 30 Mar 2007 13:53:14 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On giovedì 29 marzo 2007, Jeff Dike wrote:
> On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote:
> > > Sometimes you need to. I'd probably just remove the do_ubd check and
> > > always recall the request function when handling completions, it's
> > > easier and safe.
> If I'm understanding this correctly, this is what happens now.  There
> is still the flag check and return if the queue is being run, but I
> don't see the advantage of removing that.
> > Anyway, the main speedups to do on the UBD driver are:
> > * implement write barriers (so much less fsync) - this is performance
> > killer n.1
> You mean preventing the upper layers from calling fsync?

No. Since we don't know when the upper layers (including the journaling layer) 
wants to fsync, we call it everytime. But they pass this information. Chris 
Lightfoot implemented write barriers just before the API was changed, 
together with much of the other stuff I'm talking about.

It's impressive to check his original mail - the scenario with create a 32M 
file + delete it, where delete takes a minute on vanilla and 1 second on his 
patched code. I've downloaded the patch for future reference, even if I don't 
know when I'll have time to look at it.

> > * possibly to use the new 2.6 request layout with scatter/gather I/O, and
> > vectorized I/O on the host
> Yeah, this is something I've thought about on occassion but never
> done.
> > * while at vectorizing I/O using async I/O
> I have that, but haven't merged it since I see no performance benefit
> for some reason.
> > * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes
> > cpu-bound.
> Right - I cooked up a scheme a while ago that had the requests on a
> list, being removed from one end and added to the other, with some
> minimal number of bytes going across the pipe to ensure a wakeup if
> the other side was possibly asleep.  But I never implemented it.
> > * using futexes instead of pipes for synchronization (required for
> > previous one).
> Yup - for this, we either need to test the host for futuxes and use
> pipes as a fallback or give up on 2.4 as the host.
> > I forgot one thing: remember ubd=mmap? Something like that could have
> > been done using MAP_PRIVATE, so that write had still to be called
> > explicitly but unchanged data was shared with the host.
> >
> > Once a page gets dirty but is then cleaned, sharing it back is
> > difficult - but even without that good savings could be
> > achievable. That's to explore for the very future though.
> Interesting idea.  That does avoid the formerly fatal mmap problem.
> If you unmap it, the private copy goes away because it lost its last
> reference, and if you map it again, you get the shared version.
> That's a lot of mapping and unmapping though.  I wonder if just
> calling mmap would cause the COWed page to be dropped...
> 				Jeff

Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade

  reply	other threads:[~2007-03-30 11:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-28  2:02 Jeff Dike
2007-03-29  0:36 ` [uml-devel] " Blaisorblade
2007-03-29  1:02   ` Blaisorblade
2007-03-29 18:29   ` Jeff Dike
2007-03-30 11:53     ` Blaisorblade [this message]
2007-03-31 14:17     ` Blaisorblade

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:

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

  git send-email \ \ \ \ \ \ \
    --subject='Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).