linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-mm@kvack.org, peterz@infradead.org
Subject: Re: [PATCH 0/2 v2] Flexible proportions for BDIs
Date: Fri, 11 May 2012 22:51:14 +0800	[thread overview]
Message-ID: <20120511145114.GA18227@localhost> (raw)
In-Reply-To: <20120510073123.GA7523@localhost>

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

> > > Look at the gray "bdi setpoint" lines. The
> > > VM_COMPLETIONS_PERIOD_LEN=8s kernel is able to achieve roughly the
> > > same stable bdi_setpoint as the vanilla kernel, while being able to
> > > adapt to the balanced bdi_setpoint much more fast (actually now the
> > > bdi_setpoint is immediately close to the balanced value when
> > > balance_dirty_pages() starts throttling, while the vanilla kernel
> > > takes about 20 seconds for bdi_setpoint to grow up).
> >   Which graph is from which kernel? All four graphs have the same name so
> > I'm not sure...
> 
> They are for test cases:
> 
> 0.5s period
>         bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.4.0-rc2-prop+/balance_dirty_pages-pages+.png
> 3s period
>         bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.4.0-rc2-prop3+/balance_dirty_pages-pages+.png
> 8s period
>         bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.4.0-rc2-prop8+/balance_dirty_pages-pages+.png
> vanilla
>         bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.3.0/balance_dirty_pages-pages+.png
> 
> >   The faster (almost immediate) initial adaptation to bdi's writeout fraction
> > is mostly an effect of better normalization with my patches. Although it is
> > pleasant, it happens just at the moment when there is a small number of
> > periods with non-zero number of events. So more important for practice is
> > in my opininion to compare transition of computed fractions when workload
> > changes (i.e. we start writing to one bdi while writing to another bdi or
> > so).
> 
> OK. I'll test this scheme and report back.
> 
>         loop {
>                 dd to disk 1 for 30s
>                 dd to disk 2 for 30s
>         }

Here are the new results. For simplicity I run the dd dirtiers
continuously, and start another dd reader to knock down the write
bandwidth from time to time:

         loop {
                 dd from disk 1 for 30s
                 dd from disk 2 for 30s
         }

The first attached iostat graph shows the resulting read/write
bandwidth for one of the two disks.

The followed graphs are for
        - 3s period
        - 8s period
        - vanilla
in order. The test case is (xfs-1dd, mem=2GB, 2 disks JBOD).

Thanks,
Fengguang

[-- Attachment #2: iostat-bw.png --]
[-- Type: image/png, Size: 131686 bytes --]

[-- Attachment #3: balance_dirty_pages-pages.png --]
[-- Type: image/png, Size: 283309 bytes --]

[-- Attachment #4: balance_dirty_pages-pages.png --]
[-- Type: image/png, Size: 266833 bytes --]

[-- Attachment #5: balance_dirty_pages-pages.png --]
[-- Type: image/png, Size: 255150 bytes --]

  reply	other threads:[~2012-05-11 14:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03 22:39 [PATCH 0/2 v2] Flexible proportions for BDIs Jan Kara
2012-05-03 22:39 ` [PATCH 1/2] lib: Proportions with flexible period Jan Kara
2012-05-03 22:39 ` [PATCH 2/2] block: Convert BDI proportion calculations to flexible proportions Jan Kara
2012-05-07 14:47   ` Fengguang Wu
2012-05-07 15:21     ` Peter Zijlstra
2012-05-09 11:38       ` Jan Kara
2012-05-07 14:43 ` [PATCH 0/2 v2] Flexible proportions for BDIs Fengguang Wu
2012-05-09 11:37   ` Jan Kara
2012-05-10  7:31     ` Fengguang Wu
2012-05-11 14:51       ` Fengguang Wu [this message]
2012-05-13  3:29         ` Fengguang Wu
2012-05-14 21:28           ` Jan Kara
2012-05-15 11:12             ` Peter Zijlstra
2012-05-15 15:14               ` Jan Kara
2012-05-15 13:15             ` Fengguang Wu
2012-05-14 21:12         ` Jan Kara

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=20120511145114.GA18227@localhost \
    --to=fengguang.wu@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.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).