linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [RFC PATCH 0/5] IO-less balance dirty pages
Date: Sun, 06 Feb 2011 19:54:37 +0200	[thread overview]
Message-ID: <4D4EE05D.4050906@panasas.com> (raw)
In-Reply-To: <1296783534-11585-1-git-send-email-jack@suse.cz>

On 02/04/2011 03:38 AM, Jan Kara wrote:
>   Hi,
> 
>   I've decided to take my stab at trying to make balance_dirty_pages() not
> submit IO :). I hoped to have something simpler than Fengguang and we'll see
> whether it is good enough.
> 
> The basic idea (implemented in the third patch) is that processes throttled
> in balance_dirty_pages() wait for enough IO to complete. The waiting is
> implemented as follows: Whenever we decide to throttle a task in
> balance_dirty_pages(), task adds itself to a list of tasks that are throttled
> against that bdi and goes to sleep waiting to receive specified amount of page
> IO completions. Once in a while (currently HZ/10, in patch 5 the interval is
> autotuned based on observed IO rate), accumulated page IO completions are
> distributed equally among waiting tasks.
> 
> This waiting scheme has been chosen so that waiting time in
> balance_dirty_pages() is proportional to
>   number_waited_pages * number_of_waiters.
> In particular it does not depend on the total number of pages being waited for,
> thus providing possibly a fairer results.
> 
> I gave the patches some basic testing (multiple parallel dd's to a single
> drive) and they seem to work OK. The dd's get equal share of the disk
> throughput (about 10.5 MB/s, which is nice result given the disk can do
> about 87 MB/s when writing single-threaded), and dirty limit does not get
> exceeded. Of course much more testing needs to be done but I hope it's fine
> for the first posting :).
> 
> Comments welcome.
> 
> 								Honza

So what is the disposition of Wu's patches in light of these ones?
* Do they replace Wu's, or Wu's just get rebased ontop of these at a
  later stage?
* Did you find any hard problems with Wu's patches that delay them for
  a long time?
* Some of the complicated stuff in Wu's patches are the statistics and
  rate control mechanics. Are these the troubled area? Because some of
  these are actually some things that I'm interested in, and that appeal
  to me the most.

In short why aren't Wu's patches ready to be included in 2.6.39?

Thanks
Boaz

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2011-02-06 17:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-04  1:38 [RFC PATCH 0/5] IO-less balance dirty pages Jan Kara
2011-02-04  1:38 ` [PATCH 1/5] writeback: account per-bdi accumulated written pages Jan Kara
2011-02-04  1:38 ` [PATCH 2/5] mm: Properly reflect task dirty limits in dirty_exceeded logic Jan Kara
2011-02-04  1:38 ` [PATCH 3/5] mm: Implement IO-less balance_dirty_pages() Jan Kara
2011-02-04 13:09   ` Peter Zijlstra
2011-02-11 14:56     ` Jan Kara
2011-02-04 13:09   ` Peter Zijlstra
2011-02-04 13:19     ` Peter Zijlstra
2011-02-11 15:46     ` Jan Kara
2011-02-22 15:40       ` Peter Zijlstra
2011-02-04 13:09   ` Peter Zijlstra
2011-02-11 14:56     ` Jan Kara
2011-02-04  1:38 ` [PATCH 4/5] mm: Remove low limit from sync_writeback_pages() Jan Kara
2011-02-04  1:38 ` [PATCH 5/5] mm: Autotune interval between distribution of page completions Jan Kara
2011-02-04 13:09   ` Peter Zijlstra
2011-02-11 15:49     ` Jan Kara
2011-02-06 17:54 ` Boaz Harrosh [this message]
2011-02-09 23:30   ` [RFC PATCH 0/5] IO-less balance dirty pages Jan Kara
2011-02-10 12:08     ` Boaz Harrosh

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=4D4EE05D.4050906@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=fengguang.wu@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.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 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).