All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
To: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Cc: yumiko.sugita.yf@hitachi.com, masami.hiramatsu.pt@hitachi.com,
	hidehiro.kawai.ez@hitachi.com, yuji.kakutani.uw@hitachi.com,
	soshima@redhat.com, haoki@redhat.com,
	kamezawa.hiroyu@jp.fujitsu.com, nikita@clusterfs.com,
	leroy.vanlogchem@wldelft.nl
Subject: [PATCH 3/3] VM throttling: Break on no more Dirty pages
Date: Wed, 14 Mar 2007 21:43:44 +0900	[thread overview]
Message-ID: <45F7EE00.4080004@hitachi.com> (raw)

This modifies balance_dirty_pages() not to block the caller when
the amount of Dirty+Writeback is less than `vm.dirty_limit_ratio'
percent of the total memory.
In that case, the generator of the dirty pages are throttled in the
write-requests-queue of the backing device.

throttle_vm_writeout() is also changed to calculate the threshold from
the new limit provided by modified get_dirty_limits().

Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
Signed-off-by: Yuji Kakutani <yuji.kakutani.uw@hitachi.com>
---
 mm/page-writeback.c |   28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

Index: linux-2.6.21-rc3-mm2/mm/page-writeback.c
===================================================================
--- linux-2.6.21-rc3-mm2.orig/mm/page-writeback.c
+++ linux-2.6.21-rc3-mm2/mm/page-writeback.c
@@ -219,12 +219,15 @@ get_dirty_limits(long *pbackground, long
  * balance_dirty_pages() must be called by processes which are generating dirty
  * data.  It looks at the number of dirty pages in the machine and will force
  * the caller to perform writeback if the system is over `vm_dirty_ratio'.
+ * If the caller couldn't writeback `write_chunk' pages and we're over
+ * `dirty_limit', the caller will be blocked in congestion_wait().
  * If we're over `background_thresh' then pdflush is woken to perform some
  * writeout.
  */
 static void balance_dirty_pages(struct address_space *mapping)
 {
 	long nr_reclaimable;
+	long nr_dirty;
 	long background_thresh;
 	long dirty_thresh;
 	long dirty_limit;
@@ -246,9 +249,9 @@ static void balance_dirty_pages(struct a
 							&dirty_limit, mapping);
 		nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
 					global_page_state(NR_UNSTABLE_NFS);
-		if (nr_reclaimable + global_page_state(NR_WRITEBACK) <=
-			dirty_thresh)
-				break;
+		nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK);
+		if (nr_dirty <= dirty_thresh)
+			break;

 		if (!dirty_exceeded)
 			dirty_exceeded = 1;
@@ -265,20 +268,21 @@ static void balance_dirty_pages(struct a
 					 		&dirty_limit, mapping);
 			nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
 					global_page_state(NR_UNSTABLE_NFS);
-			if (nr_reclaimable +
-				global_page_state(NR_WRITEBACK)
-					<= dirty_thresh)
-						break;
+			nr_dirty = nr_reclaimable +
+					global_page_state(NR_WRITEBACK);
+			if (nr_dirty <= dirty_thresh)
+				break;
 			pages_written += write_chunk - wbc.nr_to_write;
 			if (pages_written >= write_chunk)
 				break;		/* We've done our duty */
+			if (nr_dirty <= dirty_limit)
+				break;		/* no more dirty pages on bdi */
 		}
 		congestion_wait(WRITE, HZ/10);
 	}

-	if (nr_reclaimable + global_page_state(NR_WRITEBACK)
-		<= dirty_thresh && dirty_exceeded)
-			dirty_exceeded = 0;
+	if (nr_dirty <= dirty_thresh && dirty_exceeded)
+		dirty_exceeded = 0;

 	if (writeback_in_progress(bdi))
 		return;		/* pdflush is already working this queue */
@@ -372,10 +376,10 @@ void throttle_vm_writeout(gfp_t gfp_mask
                  * Boost the allowable dirty threshold a bit for page
                  * allocators so they don't get DoS'ed by heavy writers
                  */
-                dirty_thresh += dirty_thresh / 10;      /* wheeee... */
+                dirty_limit += dirty_limit / 10;      /* wheeee... */

                 if (global_page_state(NR_UNSTABLE_NFS) +
-			global_page_state(NR_WRITEBACK) <= dirty_thresh)
+			global_page_state(NR_WRITEBACK) <= dirty_limit)
                         	break;
                 congestion_wait(WRITE, HZ/10);
         }


                 reply	other threads:[~2007-03-14 12:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=45F7EE00.4080004@hitachi.com \
    --to=tomoki.sekiyama.qu@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=haoki@redhat.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=leroy.vanlogchem@wldelft.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=nikita@clusterfs.com \
    --cc=soshima@redhat.com \
    --cc=yuji.kakutani.uw@hitachi.com \
    --cc=yumiko.sugita.yf@hitachi.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 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.