Hi,
On Wed, Apr 26, 2000 at 04:14:08PM -0600, Jim Schutt wrote:
>
> I've been studying the code for kiobufs to make sure I understand
> how to use them. I could use some help understanding the following:
>
> - The comment above map_user_kiobuf(), as well as its usage in rw_raw_dev(),
> implies that it is responsible for pinning down the user pages in
> physical memory. It seems to me that the call to handle_mm_fault() is
> responsible for ensuring each page is in physical memory, but what
> is responsible for pinning them there?
Incrementing the page's reference count is sufficient to pin the page.
It won't pin the pte references in the caller's page tables, but if we
do end up unmapping the page, the physical page will still stay in
memory and a soft page fault on that virtual address will reestablish
the pte.
> - lock_kiovec() tries to set the PG_locked bit for each page it holds
> using TryLockPage() . What does this bit do if setting it
> doesn't pin the page in physical memory?
PG_locked is for I/O interlocking, for cases where you want to make sure
that there is only one I/O operation in process on the page at once.
> Why doesn't map_user_kiobuf()
> need to set it for each page it faults in?
Because it is up to the caller to decide whether such I/O interlocking
is necessary. For block device I/O, it is not.
> - map_user_kiobuf() increments the count for each page, but unmap_kiobuf()
> doesn't decrement it.
Yes it does. free_page() decrements the reference count and frees the
page if it reaches zero.
> - lock_kiovec() sets the kiobuf.locked flag for each kiobuf in the
> kiovec, and both unlock_kiovec() and unmap_kiobuf() clear it. Why
> doesn't map_user_kiobuf() set it?
You already asked that. :-)
> - Under what circumstances am I likely to need lock_kiovec() and
> unlock_kiovec(), in addtion to map_user_kiobuf() and unmap_kiobuf()?
It's probably only necessary if you need to interlock the IO with other
kernel components. For example, if you populate a kiobuf from the page
cache, then you'd need to lock it before doing IO to regular files, to
synchronise with other users of the page cache.
--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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST