From: Miklos Szeredi <miklos@szeredi.hu>
To: akpm@linux-foundation.org
Cc: wfg@mail.ustc.edu.cn, a.p.zijlstra@chello.nl, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] remove throttle_vm_writeout()
Date: Thu, 04 Oct 2007 14:25:22 +0200 [thread overview]
Message-ID: <E1IdPla-0002Bd-00@dorka.pomaz.szeredi.hu> (raw)
This in preparation for the writable mmap patches for fuse. I know it
conflicts with
writeback-remove-unnecessary-wait-in-throttle_vm_writeout.patch
but if this function is to be removed, it doesn't make much sense to
fix it first ;)
---
From: Miklos Szeredi <mszeredi@suse.cz>
By relying on the global diry limits, this can cause a deadlock when
devices are stacked.
If the stacking is done through a fuse filesystem, the __GFP_FS,
__GFP_IO tests won't help: the process doing the allocation doesn't
have any special flag.
So why exactly does this function exist?
Direct reclaim does not _increase_ the number of dirty pages in the
system, so rate limiting it seems somewhat pointless.
There are two cases:
1) File backed pages -> file
dirty + writeback count remains constant
2) Anonymous pages -> swap
writeback count increases, dirty balancing will hold back file
writeback in favor of swap
So the real question is: does case 2 need rate limiting, or is it OK
to let the device queue fill with swap pages as fast as possible?
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
---
Index: linux/include/linux/writeback.h
===================================================================
--- linux.orig/include/linux/writeback.h 2007-10-02 16:55:03.000000000 +0200
+++ linux/include/linux/writeback.h 2007-10-04 13:40:33.000000000 +0200
@@ -94,7 +94,6 @@ static inline void inode_sync_wait(struc
int wakeup_pdflush(long nr_pages);
void laptop_io_completion(void);
void laptop_sync_completion(void);
-void throttle_vm_writeout(gfp_t gfp_mask);
/* These are exported to sysctl. */
extern int dirty_background_ratio;
Index: linux/mm/page-writeback.c
===================================================================
--- linux.orig/mm/page-writeback.c 2007-10-02 16:55:03.000000000 +0200
+++ linux/mm/page-writeback.c 2007-10-04 13:40:33.000000000 +0200
@@ -497,37 +497,6 @@ void balance_dirty_pages_ratelimited_nr(
}
EXPORT_SYMBOL(balance_dirty_pages_ratelimited_nr);
-void throttle_vm_writeout(gfp_t gfp_mask)
-{
- long background_thresh;
- long dirty_thresh;
-
- if ((gfp_mask & (__GFP_FS|__GFP_IO)) != (__GFP_FS|__GFP_IO)) {
- /*
- * The caller might hold locks which can prevent IO completion
- * or progress in the filesystem. So we cannot just sit here
- * waiting for IO to complete.
- */
- congestion_wait(WRITE, HZ/10);
- return;
- }
-
- for ( ; ; ) {
- get_dirty_limits(&background_thresh, &dirty_thresh, NULL, NULL);
-
- /*
- * 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... */
-
- if (global_page_state(NR_UNSTABLE_NFS) +
- global_page_state(NR_WRITEBACK) <= dirty_thresh)
- break;
- congestion_wait(WRITE, HZ/10);
- }
-}
-
/*
* writeback at least _min_pages, and keep writing until the amount of dirty
* memory is less than the background threshold, or until we're all clean.
Index: linux/mm/vmscan.c
===================================================================
--- linux.orig/mm/vmscan.c 2007-10-02 16:55:03.000000000 +0200
+++ linux/mm/vmscan.c 2007-10-04 13:40:33.000000000 +0200
@@ -1184,7 +1184,6 @@ static unsigned long shrink_zone(int pri
}
}
- throttle_vm_writeout(sc->gfp_mask);
return nr_reclaimed;
}
--
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>
next reply other threads:[~2007-10-04 12:25 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 12:25 Miklos Szeredi [this message]
2007-10-04 12:40 ` Peter Zijlstra
2007-10-04 13:00 ` Miklos Szeredi
2007-10-04 13:23 ` Peter Zijlstra
2007-10-04 13:49 ` Miklos Szeredi
2007-10-04 16:47 ` Peter Zijlstra
2007-10-04 17:46 ` Andrew Morton
2007-10-04 18:10 ` Peter Zijlstra
2007-10-04 18:54 ` Andrew Morton
[not found] ` <20071005123028.GA10372@mail.ustc.edu.cn>
2007-10-05 12:30 ` Fengguang Wu
2007-10-05 17:20 ` Andrew Morton
[not found] ` <20071006023224.GA7526@mail.ustc.edu.cn>
2007-10-06 2:32 ` Fengguang Wu
2007-10-07 23:54 ` David Chinner
[not found] ` <20071008003349.GA5455@mail.ustc.edu.cn>
2007-10-08 0:33 ` Fengguang Wu
2007-10-04 21:07 ` Miklos Szeredi
2007-10-04 21:56 ` Andrew Morton
2007-10-04 22:39 ` Miklos Szeredi
2007-10-04 23:09 ` Andrew Morton
2007-10-04 23:26 ` Miklos Szeredi
2007-10-04 23:48 ` Andrew Morton
2007-10-05 0:12 ` Miklos Szeredi
2007-10-05 0:48 ` Andrew Morton
2007-10-05 8:22 ` Peter Zijlstra
2007-10-05 9:22 ` Miklos Szeredi
2007-10-05 9:47 ` Peter Zijlstra
2007-10-05 10:27 ` Miklos Szeredi
2007-10-05 10:32 ` Miklos Szeredi
2007-10-05 15:43 ` John Stoffel
2007-10-05 10:57 ` Peter Zijlstra
2007-10-05 11:27 ` Miklos Szeredi
2007-10-05 17:50 ` Trond Myklebust
2007-10-05 18:32 ` Peter Zijlstra
2007-10-05 19:20 ` Trond Myklebust
2007-10-05 19:23 ` Trond Myklebust
2007-10-05 21:07 ` Peter Zijlstra
[not found] ` <20071006004028.GA7121@mail.ustc.edu.cn>
2007-10-06 0:40 ` Fengguang Wu
2007-10-05 7:32 ` Peter Zijlstra
2007-10-05 19:54 ` Rik van Riel
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=E1IdPla-0002Bd-00@dorka.pomaz.szeredi.hu \
--to=miklos@szeredi.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wfg@mail.ustc.edu.cn \
/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