From: Andrea Arcangeli <andrea@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: "Juan J. Quintela" <quintela@fi.udc.es>,
linux-mm@kvack.org, linux-kernel@vger.rutgers.edu
Subject: Re: classzone-VM + mapped pages out of lru_cache
Date: Thu, 4 May 2000 20:43:40 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.21.0005042022200.3416-100000@alpha.random> (raw)
In-Reply-To: <shsya5q2rdl.fsf@charged.uio.no>
On 4 May 2000, Trond Myklebust wrote:
>Not good. If I'm running /bin/bash, and somebody on the server updates
>/bin/bash, then I don't want to reboot my machine. With the above
If you use rename(2) to update the shell (as you should since `cp` would
corrupt also users that are reading /bin/bash from local fs) then nfs
should get it right also with my patch since it should notice the inode
number changed (the nfs fd handle should get the inode number as cookie),
right?
>We have to insist on the PageLocked() both in 2.2.x and 2.3.x because
>only pages which are in the process of being read in are safe. If we
>know we're scheduled to write out a full page then that would be safe
>too, but that is the only such case.
I'm not wondering about locking/coherency/read/writes.
The only problem I am wondering about is that we simply can't unlink
_mapped_ page-cache pages from the pagecache as we do now.
Say there's page A in the page cache. It gets mapped into a pte of process
X. Then before you can drop A from the page cache to invalidate it
(because such page changed on the nfs server), you _first_ have to unmap
such page from the pte of process X. This is why invalidate_inode_pages
must not unlink mapped pages. It's not a locking problem, PageLocked()
pagecache_lock and all other locks are irrelevant. It's not a race but a
design issue.
>PS: It would be nice to have truncate_inode_pages() work in the same
>way as it does now: waiting on pages and locking them. This is useful
>for reading in the directory pages, since they need to be read in
>sequentially (please see the proposed patch I put on l-k earlier
>today).
I'll look at it.
Andrea
--
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.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-05-04 18:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-03 16:26 Andrea Arcangeli
2000-05-04 0:42 ` David S. Miller
2000-05-04 10:00 ` Andrea Arcangeli
2000-05-04 14:40 ` Juan J. Quintela
2000-05-04 15:19 ` Andrea Arcangeli
2000-05-04 15:23 ` Andrea Arcangeli
2000-05-04 15:38 ` Rik van Riel
2000-05-04 17:59 ` Andrea Arcangeli
2000-05-04 19:24 ` Rik van Riel
2000-05-04 16:34 ` Manfred Spraul, Andrea Arcangeli
2000-05-04 16:48 ` Trond Myklebust
2000-05-04 18:43 ` Andrea Arcangeli [this message]
2000-05-04 19:32 ` Trond Myklebust
2000-05-04 20:15 ` Andrea Arcangeli
2000-05-05 7:01 ` Trond Myklebust
2000-05-04 16:34 ` Juan J. Quintela
2000-05-04 18:27 ` Chris Evans
[not found] <3911ECCD.BA1BB24E@arcormail.de>
2000-05-04 23:44 ` Andrea Arcangeli
2000-05-05 0:03 ` Jens Axboe
2000-05-05 3:04 ` David S. Miller
2000-05-05 8:43 ` Russell King
2000-05-05 14:56 ` Andrea Arcangeli
2000-05-06 13:37 ` Andrea Arcangeli
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=Pine.LNX.4.21.0005042022200.3416-100000@alpha.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=quintela@fi.udc.es \
--cc=trond.myklebust@fys.uio.no \
/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