Questions about upls, INACTIVATE, and PRECIOUS
Questions about upls, INACTIVATE, and PRECIOUS
- Subject: Questions about upls, INACTIVATE, and PRECIOUS
- From: Ken Hornstein <email@hidden>
- Date: Wed, 06 Apr 2011 22:02:57 -0400
I've been (probably foolishly) working on and off on porting an already-
existing network filesystem to Darwin. I'm fairly far along, and I'm now
at the point of handling data caching.
Before anyone says anything ... yes, I've read Singh's book, and I've read
the appropriate Apple documentation. They're both okay ... as starting
points. They really don't go into the detail that I need at this point;
what I've been using has been the NFS sources included in MacOS X as a
guide. Fine, okay, that's what I expect when I get to this level, and
I can deal with that.
I am having a bit of uncertainty when it comes to the exact handling of
UPLs. As I understand it (based on the NFS sources) a rough sequence
of what I need to do so data caching is integrated properly with UBC is
as follows:
- Make sure the size of my vnode is set correctly with ubc_setsize()
- Create some metadata to keep track of individual buffer status
(dirty, whatever else)
- When I need to "lock" a page within the UBC for a particular vnode,
create a UPL with ubc_create_upl().
- When I need to read/write the data, I map it into the kernel's memory
with ubc_upl_map() (I'm only doing this for reading right now).
- After I'm done copying my data, I can remove the mapping with ubc_upl_unmap().
- When I'm done completely, I commit the UPL using ubc_upl_commit().
- I can then use cluster_copy_ubc_data() to copy the data to userspace (if
I have the data already cached, I can just do this step).
So the things I am not quite clear on ...
- The semantics of PRECIOUS. Okay, the limited documentation on this says
that the pages that are marked precious are assumed to be the only copy
and that they always have to be returned to the memory manager when they
need to be evicted, even when not dirty. The NFS code always makes sure
that all pages that it is buffering are initially marked as precious.
But then when an NFS buffer is released, if (for example) the buffer
has just been used for reading then the precious flag is cleared by
the UPL_COMMIT_CLEAR_PRECIOUS flag. To me this means that if the VM
system wants to evict a page due to memory pressure it can do so without
letting NFS know via a VNOP_PAGEOUT() call. It may be that this doesn't
matter for NFS; from what I see if nfs can't copy data from the UBC using
cluster_copy_ubc_data() it just starts transferring it from the server.
So, am I right in my understanding that if I mark a page as precious, I
will always get a VNOP_PAGEOUT() for it? Does marking a page as precious
have any other side effects that I should be aware of? I see from the
kernel sources that in most places there is a test for a page being dirty
or precious at the same time, so I am guessing their semantics are close.
- What exactly does UPL_COMMIT_INACTIVATE do? The documentation in ubc_subr.c
says "Clear each pages reference bit; the page will not be accessed". The
NFS code does this for all released buffers. I know this clears the
"reference" flag in the page, but I'm not clear on what exactly this
_means_; should I always use this flag when I commit a UPL?
- If I get notification from the fileserver that pages I have cached are no
longer valid, how should I tell the UBC that? (Presume that we're already
doing the appropriate locking so no dirty client-side data will be lost).
ubc_msync() with UBC_INVALIDATE?
Thanks for any help you can give me,
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden