On Fri, 05 Nov 1999 09:29:36 -0700, "Jeff V. Merkey"
<jmerkey@timpanogas.com> said:
> Also, I noticed that brw page locks the page in memory. I am not
> doing this and am not seeing any problems, but should I? I am calling
> kmallov with GFP_BUFFER. Does this take care of the locking problem
> for IO?
There are two separate things you need to do: you need to make sure that
the page is locked (pinned) in memory, and you need to make sure it is
locked for IO. The first is to avoid reuse of the page, and the second
is to synchronise against accesses seeing the page in an inconsistent
state during IO.
Whether these matter for you depends on what you are doing with the
pages. If the pages are just being kept privately in an internal cache,
then the VM will never see them and won't care what you are doing with
them. However, if the pages are in the page cache and (a) have a page
count of one, and (b) are not locked, then the page stealer may reclaim
them.
You can protect a page from the page stealer by raising the page count
above one. You can synchronise with other users of the page trying to
access it mid-IO by locking it. They are separate things, though, and
the use of locking in brw_page is the latter IO-synchronisation type of
locking, not the lock-in-memory type of locking.
The idea behind locking for IO is largely consistent across the various
caches: the page/buffer/inode is marked locked while being read
(initialised) or written, and any other process can wait for IO to
complete by placing themselves on the object's wait queue and sleeping
until the locked bit is cleared (we always lock synchronously but unlock
events on IO completion can be asynchronous).
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/