All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	davej@redhat.com, tim.c.chen@linux.intel.com,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: Change in default vm_dirty_ratio
Date: Thu, 21 Jun 2007 17:53:20 -0500	[thread overview]
Message-ID: <20070621225320.GP11166@waste.org> (raw)
In-Reply-To: <20070620092058.GP18863@kernel.dk>

On Wed, Jun 20, 2007 at 11:20:59AM +0200, Jens Axboe wrote:
> On Wed, Jun 20 2007, Peter Zijlstra wrote:
> > On Wed, 2007-06-20 at 11:14 +0200, Jens Axboe wrote:
> > > On Wed, Jun 20 2007, Andrew Morton wrote:
> > > > Perhaps our queues are too long - if the VFS _does_ back off, it'll take
> > > > some time for that to have an effect.
> > > > 
> > > > Perhaps the fact that the queue size knows nothing about the _size_ of the
> > > > requests in the queue is a problem.
> > > 
> > > It's complicated, the size may not matter a lot. 128 sequential 512kb IO
> > > may complete faster than 128 random 4kb IO's.
> > 
> > Yes, is there any way a queue could be limited to a certain amount of
> > 'completion time' ?
> 
> Not easily, we'd need some sort of disk profile for that to be remotely
> reliable.

Perhaps we want to throw some sliding window algorithms at it. We can
bound requests and total I/O and if requests get retired too slowly we
can shrink the windows. Alternately, we can grow the window if we're
retiring things within our desired timeframe.

-- 
Mathematics is the supreme nostalgia of our time.

  parent reply	other threads:[~2007-06-21 22:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-18 21:14 Change in default vm_dirty_ratio Tim Chen
2007-06-18 23:47 ` Andrew Morton
2007-06-19  0:06   ` Linus Torvalds
2007-06-19  0:09     ` Arjan van de Ven
2007-06-19 18:41   ` John Stoffel
2007-06-19 19:04     ` Linus Torvalds
2007-06-19 19:06       ` Linus Torvalds
2007-06-19 22:33       ` David Miller
2007-06-19 19:57   ` Andi Kleen
2007-06-20  4:24   ` Dave Jones
2007-06-20  4:44     ` Andrew Morton
2007-06-20  8:35       ` Peter Zijlstra
2007-06-20  8:58         ` Andrew Morton
2007-06-20  9:14           ` Jens Axboe
2007-06-20  9:19             ` Peter Zijlstra
2007-06-20  9:20               ` Jens Axboe
2007-06-20  9:43                 ` Peter Zijlstra
2007-06-21 22:53                 ` Matt Mackall [this message]
2007-06-21 23:08                   ` Linus Torvalds
2007-06-23 18:23                     ` Peter Zijlstra
2007-06-24 16:40                       ` Linus Torvalds
2007-06-25  0:15                         ` Peter Zijlstra
2007-06-20  9:19           ` Peter Zijlstra
2007-06-21 16:54           ` Mark Lord
2007-06-21 16:55             ` Peter Zijlstra
2007-06-20 17:17         ` Linus Torvalds
2007-06-20 18:12           ` Arjan van de Ven
2007-06-20 18:28             ` Linus Torvalds
2007-06-21 12:37     ` Nadia Derbey

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=20070621225320.GP11166@waste.org \
    --to=mpm@selenic.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.