diff for duplicates of <20110517060001.GC24069@localhost> diff --git a/a/1.txt b/N1/1.txt index f9bbdbc..7672a1f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -9,7 +9,7 @@ On Sun, May 15, 2011 at 12:12:36PM -0400, Andrew Lutomirski wrote: > >> >> If it's a culprit, the patch should solve the problem. > >> > > >> > It would be probably better to not do the allocations at all under -> >> > memory pressure. Even if the RA allocation doesn't go into reclaim +> >> > memory pressure. A Even if the RA allocation doesn't go into reclaim > >> > >> Fair enough. > >> I think we can do it easily now. @@ -22,7 +22,7 @@ On Sun, May 15, 2011 at 12:12:36PM -0400, Andrew Lutomirski wrote: > > > > The sequential readahead memory consumption can be estimated by > > -> > 2 * (number of concurrent read streams) * (readahead window size) +> > A A A A A A A A 2 * (number of concurrent read streams) * (readahead window size) > > > > And you can double that when there are two level of readaheads. > > @@ -33,21 +33,21 @@ On Sun, May 15, 2011 at 12:12:36PM -0400, Andrew Lutomirski wrote: > > GFP_NORETRY failures, so the reasonable solutions are to > > > > - shrink readahead window on readahead thrashing -> > (current readahead heuristic can somehow do this, and I have patches -> > to further improve it) +> > A (current readahead heuristic can somehow do this, and I have patches +> > A to further improve it) > > > > - prevent abnormal GFP_NORETRY failures -> > (when there are many reclaimable pages) +> > A (when there are many reclaimable pages) > > > > > > Andy's OOM memory dump (incorrect_oom_kill.txt.xz) shows that there are > > -> > - 8MB active+inactive file pages +> > - 8MB A active+inactive file pages > > - 160MB active+inactive anon pages -> > - 1GB shmem pages +> > - 1GB A shmem pages > > - 1.4GB unevictable pages > > -> > Hmm, why are there so many unevictable pages? How come the shmem +> > Hmm, why are there so many unevictable pages? A How come the shmem > > pages become unevictable when there are plenty of swap space? > > That was probably because one of my testcases creates a 1.4GB file on @@ -83,3 +83,10 @@ as I don't see how it helps your case). Thanks, Fengguang + +-- +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/ . +Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index baee88e..787388f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -29,7 +29,7 @@ "> >> >> If it's a culprit, the patch should solve the problem.\n" "> >> >\n" "> >> > It would be probably better to not do the allocations at all under\n" - "> >> > memory pressure. \302\240Even if the RA allocation doesn't go into reclaim\n" + "> >> > memory pressure. A Even if the RA allocation doesn't go into reclaim\n" "> >>\n" "> >> Fair enough.\n" "> >> I think we can do it easily now.\n" @@ -42,7 +42,7 @@ "> >\n" "> > The sequential readahead memory consumption can be estimated by\n" "> >\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\2402 * (number of concurrent read streams) * (readahead window size)\n" + "> > A A A A A A A A 2 * (number of concurrent read streams) * (readahead window size)\n" "> >\n" "> > And you can double that when there are two level of readaheads.\n" "> >\n" @@ -53,21 +53,21 @@ "> > GFP_NORETRY failures, so the reasonable solutions are to\n" "> >\n" "> > - shrink readahead window on readahead thrashing\n" - "> > \302\240(current readahead heuristic can somehow do this, and I have patches\n" - "> > \302\240to further improve it)\n" + "> > A (current readahead heuristic can somehow do this, and I have patches\n" + "> > A to further improve it)\n" "> >\n" "> > - prevent abnormal GFP_NORETRY failures\n" - "> > \302\240(when there are many reclaimable pages)\n" + "> > A (when there are many reclaimable pages)\n" "> >\n" "> >\n" "> > Andy's OOM memory dump (incorrect_oom_kill.txt.xz) shows that there are\n" "> >\n" - "> > - 8MB \302\240 active+inactive file pages\n" + "> > - 8MB A active+inactive file pages\n" "> > - 160MB active+inactive anon pages\n" - "> > - 1GB \302\240 shmem pages\n" + "> > - 1GB A shmem pages\n" "> > - 1.4GB unevictable pages\n" "> >\n" - "> > Hmm, why are there so many unevictable pages? \302\240How come the shmem\n" + "> > Hmm, why are there so many unevictable pages? A How come the shmem\n" "> > pages become unevictable when there are plenty of swap space?\n" "> \n" "> That was probably because one of my testcases creates a 1.4GB file on\n" @@ -102,6 +102,13 @@ " }\n" "\n" "Thanks,\n" - Fengguang + "Fengguang\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" + "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -45b8f658532a36dafce9be9f84c2aa00504e4130ed013dfb42607df7778bc7e5 +310a681c58c8362fd7526a76d2b5445f84710d0b1360ff8c5c13782ce969b494
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.