Thread (7 messages) 7 messages, 2 authors, 2008-10-16

Re: [PATCH] vmscan: set try_to_release_page's gfp_mask to 0

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2008-10-16 02:55:26
Also in: linux-mm, lkml

On Thu, 16 Oct 2008 11:44:39 +0900 Hisashi Hifumi [off-list ref] wrote:
Hi Andrew.
quoted
Hisashi Hifumi [off-list ref] wrote:
quoted
At 12:21 08/08/13, Andrew Morton wrote:
quoted
On Wed, 13 Aug 2008 11:21:16 +0900 Hisashi Hifumi 
[off-list ref] wrote:
quoted
quoted
quoted
quoted
Signed-off-by: Hisashi Hifumi <redacted>

diff -Nrup linux-2.6.27-rc2.org/mm/vmscan.c 
linux-2.6.27-rc2.vmscan/mm/vmscan.c
quoted
quoted
quoted
--- linux-2.6.27-rc2.org/mm/vmscan.c	2008-08-11 14:33:24.000000000 +0900
+++ linux-2.6.27-rc2.vmscan/mm/vmscan.c	2008-08-12 18:57:05.000000000 +0900
@@ -614,7 +614,7 @@ static unsigned long shrink_page_list(st
 		* Otherwise, leave the page on the LRU so it is swappable.
 		*/
 		if (PagePrivate(page)) {
-			if (!try_to_release_page(page, sc->gfp_mask))
+			if (!try_to_release_page(page, 0))
 				goto activate_locked;
 			if (!mapping && page_count(page) == 1) {
 				unlock_page(page);
I think the change makes sense.

Has this change been shown to improve any workloads?  If so, please
provide full information for the changelog.  If not, please mention
this and explain why benefits were not demonstrable.  This information
should _always_ be present in a "performance" patch's changelog!
Sorry, I do not have performance number yet. I'll try this.
Unfortunately, I did not succeed to get good performance number that
prove this patch had some benefit.
OK, thanks, I dropped it.
quoted
This patch remains in a stalled state...

And then there's this:
quoted
: 
: Really, I think what this patch tells us is that 3f31fddf ("jbd: fix
: race between free buffer and commit transaction") was an unpleasant
: hack which had undesirable and unexpected side-effects.  I think - that
: depends upon your as-yet-undisclosed testing results?
: 
: Perhaps we should revert 3f31fddf and have another think about how to
: fix the direct-io -EIO problem.  One option would be to hold our noses
: and add a new gfp_t flag for this specific purpose?
:
direct-io -EIO problem was already fixed by following patch.

commit 6ccfa806a9cfbbf1cd43d5b6aa47ef2c0eb518fd
Author: Hisashi Hifumi [off-list ref]
Date:   Tue Sep 2 14:35:40 2008 -0700

    VFS: fix dio write returning EIO when try_to_release_page fails

Dio falls back to buffered write when dio write gets EIO due to failure of try_to_release_page
by above patch. So I think just reverting the patch 3f31fddf ("jbd: fix race between 
free buffer and commit transaction") is good approach.
Fair enough.  Could I ask that you (or someone) send a suitable patch
sometime?

I could generate the patch, but I'd never get around to testing it. 
Too busy fixing rejects and compile errors :(
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help