diff for duplicates of <444F7250.2070200@redhat.com> diff --git a/a/1.txt b/N1/1.txt index f54169b..9b3ef7a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,11 +1,10 @@ Trond Myklebust wrote: >On Tue, 2006-04-25 at 21:14 -0400, Steve Dickson wrote: -> =20 +> > >>Currently the NFS client caches ACCESS information on a per uid basis ->>which fall apart when different process with different uid consistent= -ly +>>which fall apart when different process with different uid consistently >>access the same directory. The end result being a storm of needless >>ACCESS calls... >> @@ -14,48 +13,39 @@ ly >>attributes timeout.. The table is indexed by the addition of the >>nfs_inode pointer and the cr_uid in the cred structure which should >>spread things out nicely for some decent scalability (although the ->>locking scheme may need to be reworked a bit). The table has 256 entr= -ies +>>locking scheme may need to be reworked a bit). The table has 256 entries >>of struct list_head giving it a total size of 2k. ->> =20 +>> >> > ->Instead of having the field 'id', why don't you let the nfs_inode keep= - a +>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. > >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'=EAtre f= -or a +>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). ->How about rather changing that hash table into an LRU list, then addin= -g +>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? > -Previous implementations have shown that a single per inode linear=20 +Previous implementations have shown that a single per inode linear linked list -ends up not being scalable enough in certain situations. There would e= -nd up +ends up not being scalable enough in certain situations. There would end up being too many entries in the list and searching the list would become a bottleneck. Adding a set of hash buckets per inode also proved to be -inefficient because in order to have enough hash buckets to make the ha= -shing +inefficient because in order to have enough hash buckets to make the hashing efficient, much space was wasted. Having a single set of hash buckets, adequately sized, ended up being the best solution. -Why have a limit? A better solution is to have the cache grow dynamica= -lly -as need requires and then have the system reclaim the memory when it st= -arts +Why have a limit? A better solution is to have the cache grow dynamically +as need requires and then have the system reclaim the memory when it starts to run low on memory. ps - -To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= -" in +To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 5cf1ca1..9f573c9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,11 +12,10 @@ "Trond Myklebust wrote:\n" "\n" ">On Tue, 2006-04-25 at 21:14 -0400, Steve Dickson wrote:\n" - "> =20\n" + "> \n" ">\n" ">>Currently the NFS client caches ACCESS information on a per uid basis\n" - ">>which fall apart when different process with different uid consistent=\n" - "ly\n" + ">>which fall apart when different process with different uid consistently\n" ">>access the same directory. The end result being a storm of needless\n" ">>ACCESS calls...\n" ">>\n" @@ -25,50 +24,41 @@ ">>attributes timeout.. The table is indexed by the addition of the\n" ">>nfs_inode pointer and the cr_uid in the cred structure which should\n" ">>spread things out nicely for some decent scalability (although the\n" - ">>locking scheme may need to be reworked a bit). The table has 256 entr=\n" - "ies\n" + ">>locking scheme may need to be reworked a bit). The table has 256 entries\n" ">>of struct list_head giving it a total size of 2k.\n" - ">> =20\n" + ">> \n" ">>\n" ">\n" - ">Instead of having the field 'id', why don't you let the nfs_inode keep=\n" - " a\n" + ">Instead of having the field 'id', why don't you let the nfs_inode keep a\n" ">small (hashed?) list of all the nfs_access_entry objects that refer to\n" ">it? That would speed up searches for cached entries.\n" ">\n" ">I agree with Neil's assessment that we need a bound on the size of the\n" - ">cache. In fact, enforcing a bound is pretty much the raison d'=EAtre f=\n" - "or a\n" + ">cache. In fact, enforcing a bound is pretty much the raison d'\303\252tre for a\n" ">global table (by which I mean that if we don't need a bound, then we\n" ">might as well cache everything in the nfs_inode).\n" - ">How about rather changing that hash table into an LRU list, then addin=\n" - "g\n" + ">How about rather changing that hash table into an LRU list, then adding\n" ">a shrinker callback (using set_shrinker()) to allow the VM to free up\n" ">entries when memory pressure dictates that it must?\n" ">\n" "\n" - "Previous implementations have shown that a single per inode linear=20\n" + "Previous implementations have shown that a single per inode linear \n" "linked list\n" - "ends up not being scalable enough in certain situations. There would e=\n" - "nd up\n" + "ends up not being scalable enough in certain situations. There would end up\n" "being too many entries in the list and searching the list would become\n" "a bottleneck. Adding a set of hash buckets per inode also proved to be\n" - "inefficient because in order to have enough hash buckets to make the ha=\n" - "shing\n" + "inefficient because in order to have enough hash buckets to make the hashing\n" "efficient, much space was wasted. Having a single set of hash buckets,\n" "adequately sized, ended up being the best solution.\n" "\n" - "Why have a limit? A better solution is to have the cache grow dynamica=\n" - "lly\n" - "as need requires and then have the system reclaim the memory when it st=\n" - "arts\n" + "Why have a limit? A better solution is to have the cache grow dynamically\n" + "as need requires and then have the system reclaim the memory when it starts\n" "to run low on memory.\n" "\n" " ps\n" "-\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-fsdevel=\n" - "\" in\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-fsdevel\" in\n" "the body of a message to majordomo@vger.kernel.org\n" More majordomo info at http://vger.kernel.org/majordomo-info.html -dc60c07341598d24cd2c9dc679b750f95dbe164c4f1a58a57a548f81a8b18334 +68b2682ec8fa6b5d33a4988aa09b149c095ff46dafac108b295786e586a531cf
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.