Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Sun, 7 Nov 1999 23:00:14 +0000 (GMT) | Subject | Re: Linux Buffer Cache & Mirroring |
| |
Hi,
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/
| |