linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	miklos@szeredi.hu, akpm@linux-foundation.org, dgc@sgi.com,
	tomoki.sekiyama.qu@hitachi.com, nikita@clusterfs.com,
	trond.myklebust@fys.uio.no, yingchao.zhou@gmail.com
Subject: Re: [PATCH 00/15] per device dirty throttling -v6
Date: Tue, 15 May 2007 14:48:04 +1000	[thread overview]
Message-ID: <17993.15236.442636.502640@notabene.brown> (raw)
In-Reply-To: message from Peter Zijlstra on Thursday May 10

On Thursday May 10, a.p.zijlstra@chello.nl wrote:
> The latest version of the per device dirty throttling patches.
> 
> I put in quite a few comments, and added an patch to do per task dirty
> throttling as well, for RFCs sake :-)
> 
> I haven't yet come around to do anything but integrety testing on this code
> base, ie. it built a kernel. I hope to do more tests shorty if time permits...
> 
> Perhaps the people on bugzilla.kernel.org #7372 might be willing to help out
> there.
> 
> Oh, patches are against 2.6.21-mm2
> 
> -- 

Patch 12 has:
  +#include <linux/proportions.h>

But that file isn't added until patch 14.

Splitting the "proportions" stuff out into lib/ is a good idea.
You have left some remnants of it's origin though, which mentions of
   BDI
   pages
   total page writeback

The "proportions" library always uses a percpu counter, which is
perfect of the per-bdi counter, but seems wrong when you use the same
code for per-task throttling.  Have a percpu counter in struct task
seems very wasteful.  You don't need to lock the access to this
counter as it is only ever access as current-> so a simple "long"
(or "long long") would do.  The global "vm_dirties" still needs to be
percpu....  I'm not sure what best to do about this.

   
The per-task throttling is interesting.
You reduce the point where a task has to throttle by up to half, based
on the fraction of recently dirtied pages that the task is responsible
for.
So if there is one writer, it now gets only half the space that it
used to.  That is probably OK, we can just increase the space
available...
If there are two equally eager writers, they can both use up to the
75% mark, so they probably each get 37%, which is reasonable.
If there is one fast an one slow writer where the slow writer is
generating dirty pages well below the writeout rate of the device, the
fast writer will throttle at around 50% and the slow writer will never
block.  That is nice.

If you have two writers A and B writing aggressively to two devices X
and Y with different speeds, say X twice the speed of Y, then in the
steady state, X gets 2/3 of the space and Y gets 1/3.
A will dirty twice the pages that B dirties so A will get to use
1 - (2/3)/2 == 2/3 of that space or 4/9, and B will get to use 1 - (1/3)/2 ==
5/6 of that space or 5/18.  Did I get that right?
So they will each reduce the space available to the other, even though
they aren't really competing.   That might not be a problem, but it is
interesting... 

It seems that the 'one half' is fairly arbitrary.  It could equally
well be 3/4.  That would simply mean there is less differentiation
between the more and less aggressive writer.  I would probably lean
towards a higher number like 3/4.  It should still give reasonable
differentiation without cutting max amount of dirty memory in half for
the common 1-writer case.

A couple of years ago Andrea Arcangeli wrote a patch that did per-task
throttling, which it is worth comparing with.
  http://lwn.net/Articles/152277/

It takes each task separately, measure rate-of-dirtying over a fixed
time period, and throttle when that rate would put the system over the
limit soon.  Thus slower dirtiers throttle later.

Having to configure the fixed number (the period) is always awkward,
and I think your floating average is better suited for the task.
I doubt if Andrea's patch still applies so a direct comparison might
be awkward, but it might not hurt to read through it if you haven't
already. 

NeilBrown

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

  parent reply	other threads:[~2007-05-15  4:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-10 10:08 Peter Zijlstra
2007-05-10 10:08 ` [PATCH 01/15] nfs: remove congestion_end() Peter Zijlstra
2007-05-10 10:08 ` [PATCH 02/15] lib: percpu_counter variable batch Peter Zijlstra
2007-05-10 10:08 ` [PATCH 03/15] lib: percpu_counter_mod64 Peter Zijlstra
2007-05-10 10:08 ` [PATCH 04/15] lib: percpu_counter_set Peter Zijlstra
2007-05-10 10:08 ` [PATCH 05/15] lib: percpu_count_sum_signed() Peter Zijlstra
2007-05-10 10:08 ` [PATCH 06/15] mm: bdi init hooks Peter Zijlstra
2007-05-10 10:08 ` [PATCH 07/15] mtd: give mtdconcat devices their own backing_dev_info Peter Zijlstra
2007-05-10 10:08 ` [PATCH 08/15] mm: scalable bdi statistics counters Peter Zijlstra
2007-05-10 10:08 ` [PATCH 09/15] mm: count reclaimable pages per BDI Peter Zijlstra
2007-05-10 10:08 ` [PATCH 10/15] mm: count writeback " Peter Zijlstra
2007-05-10 10:08 ` [PATCH 11/15] mm: expose BDI statistics in sysfs Peter Zijlstra
2007-05-10 10:08 ` [PATCH 12/15] mm: per device dirty threshold Peter Zijlstra
2007-05-10 10:08 ` [PATCH 13/15] debug: sysfs files for the current ratio/size/total Peter Zijlstra
2007-05-10 10:08 ` [PATCH 14/15] lib: abstract the floating proportion Peter Zijlstra
2007-05-10 10:08 ` [PATCH 15/15] mm: dirty balancing for tasks Peter Zijlstra
2007-05-15  4:48 ` Neil Brown [this message]
2007-05-15  7:44   ` [PATCH 00/15] per device dirty throttling -v6 Peter Zijlstra

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=17993.15236.442636.502640@notabene.brown \
    --to=neilb@suse.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dgc@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=nikita@clusterfs.com \
    --cc=tomoki.sekiyama.qu@hitachi.com \
    --cc=trond.myklebust@fys.uio.no \
    --cc=yingchao.zhou@gmail.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