diff for duplicates of <444F8BB5.2000700@RedHat.com> diff --git a/a/1.txt b/N1/1.txt index 7fd1158..0744e2b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,10 +1,8 @@ Trond Myklebust wrote: ->=20 ->=20 -> Instead of having the field 'id', why don't you let the nfs_inode kee= -p a -> small (hashed?) list of all the nfs_access_entry objects that refer t= -o +> +> +> 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 @@ -12,16 +10,13 @@ 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 th= -e -> cache. In fact, enforcing a bound is pretty much the raison d'=C3=AAt= -re for a +> 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 addi= -ng +> 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 @@ -30,7 +25,6 @@ correct? steved. - -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 227633a..d9c72c6 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,12 +9,10 @@ "\00:1\0" "b\0" "Trond Myklebust wrote:\n" - ">=20\n" - ">=20\n" - "> Instead of having the field 'id', why don't you let the nfs_inode kee=\n" - "p a\n" - "> small (hashed?) list of all the nfs_access_entry objects that refer t=\n" - "o\n" + "> \n" + "> \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" "Actually I did look into having a pointer in the nfs_inode... but\n" "what do you do when the second hashed list is needed. Meaning\n" @@ -22,16 +20,13 @@ "I thought it was a bit messy to keep overwriting the point in the\n" "nfs_inode so I just kept everything in the hash table...\n" "\n" - "> I agree with Neil's assessment that we need a bound on the size of th=\n" - "e\n" - "> cache. In fact, enforcing a bound is pretty much the raison d'=C3=AAt=\n" - "re for a\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'\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" "Ok..\n" "\n" - "> How about rather changing that hash table into an LRU list, then addi=\n" - "ng\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" "Sounds interesting.. Just to be clear, by LRU list you mean use hlist\n" @@ -40,9 +35,8 @@ "steved.\n" "\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 -7e9047112466c69058c3e2cc5bd66d8a392b989fbb53e13e056dda33e1b9550a +1fa6b947cabddccaaf36cf3713ff134106a60b8916d72ec81a612c5b4152fcd9
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.