Trond Myklebust wrote:
Instead of having the field 'id', why don't you let the nfs_inode keep a small (hashed?) list of all the nfs_access_entry objects that refer to it? That would speed up searches for cached entries.
Actually I did look into having a pointer in the nfs_inode... but what do you do when the second hashed list is needed. Meaning P2(uid2) comes along and hashes to a different que. I guess I thought it was a bit messy to keep overwriting the point in the nfs_inode so I just kept everything in the hash table...
I agree with Neil's assessment that we need a bound on the size of the cache. In fact, enforcing a bound is pretty much the raison d'être for a global table (by which I mean that if we don't need a bound, then we might as well cache everything in the nfs_inode).
Ok..
How about rather changing that hash table into an LRU list, then adding a shrinker callback (using set_shrinker()) to allow the VM to free up entries when memory pressure dictates that it must?
Sounds interesting.. Just to be clear, by LRU list you mean use hlist correct? steved. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
