diff for duplicates of <20090520014445.GA7645@localhost> diff --git a/a/1.txt b/N1/1.txt index 7077862..d38dd9a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -64,19 +64,19 @@ Fengguang > > Or, shall we take the "protect active VM_EXEC mapped pages" approach, > > or Christoph's "protect all mapped pages all time, unless they grow -> > too large" attitude? I still prefer the best effort VM_EXEC heuristics. +> > too large" attitude? A I still prefer the best effort VM_EXEC heuristics. > > > > 1) the partially cache hot streaming IO is far more likely to happen -> > on (file) servers. For them, evicting the 9/10 inactive mapped -> > pages over night should be acceptable for sysadms. +> > A on (file) servers. For them, evicting the 9/10 inactive mapped +> > A pages over night should be acceptable for sysadms. > > > > 2) for use-once IO on desktop, we have Rik's active file list -> > protection heuristics, so nothing to worry at all. +> > A protection heuristics, so nothing to worry at all. > > > > 3) for big working set small memory desktop, the active list will -> > still be scanned, in this situation, why not evict some of the -> > inactive mapped pages? If they have not been accessed for 1 minute, -> > they are not likely be the user focus, and the tight memory -> > constraint can only afford to cache the user focused working set. +> > A still be scanned, in this situation, why not evict some of the +> > A inactive mapped pages? If they have not been accessed for 1 minute, +> > A they are not likely be the user focus, and the tight memory +> > A constraint can only afford to cache the user focused working set. > > > > Does that make sense? diff --git a/a/content_digest b/N1/content_digest index 60e91d1..821cb55 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -86,20 +86,20 @@ "\n" "> > Or, shall we take the \"protect active VM_EXEC mapped pages\" approach,\n" "> > or Christoph's \"protect all mapped pages all time, unless they grow\n" - "> > too large\" attitude? \302\240I still prefer the best effort VM_EXEC heuristics.\n" + "> > too large\" attitude? A I still prefer the best effort VM_EXEC heuristics.\n" "> >\n" "> > 1) the partially cache hot streaming IO is far more likely to happen\n" - "> > \302\240 on (file) servers. For them, evicting the 9/10 inactive mapped\n" - "> > \302\240 pages over night should be acceptable for sysadms.\n" + "> > A on (file) servers. For them, evicting the 9/10 inactive mapped\n" + "> > A pages over night should be acceptable for sysadms.\n" "> >\n" "> > 2) for use-once IO on desktop, we have Rik's active file list\n" - "> > \302\240 protection heuristics, so nothing to worry at all.\n" + "> > A protection heuristics, so nothing to worry at all.\n" "> >\n" "> > 3) for big working set small memory desktop, the active list will\n" - "> > \302\240 still be scanned, in this situation, why not evict some of the\n" - "> > \302\240 inactive mapped pages? If they have not been accessed for 1 minute,\n" - "> > \302\240 they are not likely be the user focus, and the tight memory\n" - "> > \302\240 constraint can only afford to cache the user focused working set.\n" + "> > A still be scanned, in this situation, why not evict some of the\n" + "> > A inactive mapped pages? If they have not been accessed for 1 minute,\n" + "> > A they are not likely be the user focus, and the tight memory\n" + "> > A constraint can only afford to cache the user focused working set.\n" "> >\n" > > Does that make sense? "\01:2\0" @@ -181,4 +181,4 @@ "[vdso] 2 0 0 \n" /usr/lib/gconv/gconv-modules.cache 1 0 0 -7c440775abc09dcd4249a526bf636a9a30474aa2e286773329fc27484b7d16d8 +b8793e44949a265e0597f33ab9640c0cf5a4d885c4012cd0f3abce7d694b54d0
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.