All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Ron Maeder <rlm@orionmulti.com>
Cc: Rik van Riel <riel@surriel.com>, linux-mm@kvack.org
Subject: Re: mmap() > phys mem problem
Date: Sun, 30 May 2004 19:24:37 +1000	[thread overview]
Message-ID: <40B9A855.3030102@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.60.0405292144350.1068@stimpy>

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

Ron Maeder wrote:
> On Fri, 28 May 2004, Rik van Riel wrote:
> 
>> On Tue, 25 May 2004, Ron Maeder wrote:
>>
>>> Is this an "undocumented feature" or is this a linux error?  I would
>>> expect pages of the mmap()'d file would get paged back to the original
>>> file. I know this won't be fast, but the performance is not an issue for
>>> this application.
>>
>>
>> It looks like a kernel bug.  Can you reproduce this problem
>> with the latest 2.6 kernel or is it still there ?
>>
>> Rik
> 
> 
> I was able to reproduce the problem with the code that I posted on a 2.6.6
> kernel.
> 

Can you give this NFS patch (from Trond) a try please?

(I don't think it is a very good idea for NFS to be using
WRITEPAGE_ACTIVATE here. If NFS needs to have good write
clustering off the end of the LRU, we need to go about it
some other way.)


[-- Attachment #2: nfs-writepage.patch --]
[-- Type: text/x-patch, Size: 725 bytes --]

 linux-2.6-npiggin/fs/nfs/write.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff -puN fs/nfs/write.c~nfs-writepage fs/nfs/write.c
--- linux-2.6/fs/nfs/write.c~nfs-writepage	2004-05-30 18:46:48.000000000 +1000
+++ linux-2.6-npiggin/fs/nfs/write.c	2004-05-30 18:46:48.000000000 +1000
@@ -320,7 +320,7 @@ do_it:
 		if (err >= 0) {
 			err = 0;
 			if (wbc->for_reclaim)
-				err = WRITEPAGE_ACTIVATE;
+				nfs_flush_inode(inode, 0, 0, FLUSH_STABLE);
 		}
 	} else {
 		err = nfs_writepage_sync(NULL, inode, page, 0,
@@ -333,8 +333,7 @@ do_it:
 	}
 	unlock_kernel();
 out:
-	if (err != WRITEPAGE_ACTIVATE)
-		unlock_page(page);
+	unlock_page(page);
 	if (inode_referenced)
 		iput(inode);
 	return err; 

_

  reply	other threads:[~2004-05-30  9:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-25 22:40 mmap() > phys mem problem Ron Maeder
2004-05-29  2:08 ` Rik van Riel
2004-05-30  4:47   ` Ron Maeder
2004-05-30  9:24     ` Nick Piggin [this message]
2004-05-30 10:15       ` Andrew Morton
2004-06-05 19:21       ` Ron Maeder
2004-06-06  1:55         ` Nick Piggin
2004-06-06 23:51           ` Rik van Riel
2004-06-07  3:59             ` Nick Piggin
2004-06-07 12:04               ` Rik van Riel
2004-06-08  0:03                 ` Nick Piggin
  -- strict thread matches above, loose matches on Subject: below --
2004-06-14 22:04 Ron Maeder
2004-06-15  3:19 ` Nick Piggin
2004-06-16  3:08   ` Nick Piggin
2004-06-16  6:37     ` Ron Maeder

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=40B9A855.3030102@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=linux-mm@kvack.org \
    --cc=riel@surriel.com \
    --cc=rlm@orionmulti.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.