Hi,
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?
- 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? Why doesn't map_user_kiobuf()
need to set it for each page it faults in?
- map_user_kiobuf() increments the count for each page, but unmap_kiobuf()
doesn't decrement it. I had the impression that the page count keeps
track of the number of references to that page; if this isn't true,
what does the page count keep track of? If so, why doesn't
unmap_kiobuf() need to decrement it, as the kiobuf isn't referencing
those pages anymore? (But, presumably the user app that supplied the
buffer still is?)
- 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?
- Under what circumstances am I likely to need lock_kiovec() and
unlock_kiovec(), in addtion to map_user_kiobuf() and unmap_kiobuf()?
I.e., what extra functionality do they give me, other than looping
over multiple kiobufs?
The above questions are based on 2.3.99-pre3.
TIA for any time spent trying to enlighten me.
-- Jim
PS - Please cc: me on responses, as I follow the list through an archive.
-----------------------------------------------------------------------------
James A. Schutt Sandia National Laboratories
jaschut@sandia.gov 505 844-8882 Albuquerque, New Mexico USA
-
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:11 EST