On 08/11/2017 12:10 PM, Frank Filz wrote:
Right, this is reaping. I was thinking it was the lane thread. Reaping only
looks at the single LRU of each queue. We should probably look at some
small number of each lane, like 2 or 3.
Frank, this, in combination with the PIN lane, it probably the issue.
Yea, that would be a problem, also, consider that v4 will have much less use of
global fd under support_ex, and thus the fewer open files to trigger less
lru_run_lane events.
One option would be to promote anything that got state on it to MRU, persistent state
should (mostly) only happen if the object is going to be referenced in subsequent NFS
requests anyway (the one exception would be "touch" to create a file that is
done in a single compound (I don't know if the client actually succeeds in optimizing
that into a single compound).
I'm not worried about touch, that's open, write, close, so the refcount
drops back to 1, and it can be reaped. I'm more worried about opening a
small file in an editor (open + 1 read, potentially a single compound)
and then idling.
Also, the vector operations those research folks have been working on would
create a scenario where a file is accessed with state and done in a single
compound, which may not deserve promotion to MRU of L1 (but one way to handle
that is check on the put ref that decrements to refcount 1 if at that point
there is state on the file, if so, promote to MRU of L1).
We'll have to make other changes if this happens, I suspect.
Other than objects with persistent state, we SHOULD only have #threads * 2 (or
maybe 3 at most) active references, so as long as we set up the number of lanes
and everything right, we should still be able to reap.
I'm not quite sure I believe this. I'd have to go through things in my
mind.
Daniel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
