diff for duplicates of <56C264BF.3090100@cisco.com> diff --git a/a/1.txt b/N1/1.txt index 9dbe4eb..e2b6abc 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -65,7 +65,7 @@ also), " -Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the "time of check to time of use� window. But, this approximation works reasonably well for our use case. +Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the "time of check to time of use? window. But, this approximation works reasonably well for our use case. As to his other suggestion of estimating the droppable cache, I have considered it but found it unusable. The problem is the inactive file pages count a whole lot pages more than the droppable pages. diff --git a/a/content_digest b/N1/content_digest index 94a311e..4b62345 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -87,7 +87,7 @@ "\n" "\"\n" "\n" - "Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the \"time of check to time of use\303\257\302\277\302\275 window. But, this approximation works reasonably well for our use case.\n" + "Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the \"time of check to time of use? window. But, this approximation works reasonably well for our use case.\n" "\n" "As to his other suggestion of estimating the droppable cache, I have considered it but found it unusable. The problem is the inactive file pages count a whole lot pages more than the droppable pages.\n" "\n" @@ -114,4 +114,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -536e4abb763e109718a4aa76dcda6d0193d0d6db2e0ac85198259aacdc8f73fd +e4ce036ffeacc3827b3054954ae81f68812e5b3125656d8a3e63a2aa1334e53f
diff --git a/a/1.txt b/N2/1.txt index 9dbe4eb..4baa911 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -65,7 +65,7 @@ also), " -Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the "time of check to time of use� window. But, this approximation works reasonably well for our use case. +Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the "time of check to time of use” window. But, this approximation works reasonably well for our use case. As to his other suggestion of estimating the droppable cache, I have considered it but found it unusable. The problem is the inactive file pages count a whole lot pages more than the droppable pages. @@ -84,10 +84,3 @@ The dirty and the write back are mostly 0KB under our workload as we are mostly dealing with the readonly file pages of binaries (programs/libraries).. " - - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N2/content_digest index 94a311e..6ead28c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -87,7 +87,7 @@ "\n" "\"\n" "\n" - "Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the \"time of check to time of use\303\257\302\277\302\275 window. But, this approximation works reasonably well for our use case.\n" + "Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the \"time of check to time of use\342\200\235 window. But, this approximation works reasonably well for our use case.\n" "\n" "As to his other suggestion of estimating the droppable cache, I have considered it but found it unusable. The problem is the inactive file pages count a whole lot pages more than the droppable pages.\n" "\n" @@ -105,13 +105,6 @@ "The dirty and the write back are mostly 0KB under our workload as we are \n" "mostly dealing with the readonly file pages of binaries \n" "(programs/libraries)..\n" - "\"\n" - "\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + "\"" -536e4abb763e109718a4aa76dcda6d0193d0d6db2e0ac85198259aacdc8f73fd +4f291bedc66aeabbe409b0d548f58f61db2ba552dde1a01e7c512782ca6f49e6
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.