diff for duplicates of <20100407071408.GA17892@localhost> diff --git a/a/1.txt b/N1/1.txt index 245a0ed..dbd5be7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -28,7 +28,7 @@ On Wed, Apr 07, 2010 at 12:06:07PM +0800, Minchan Kim wrote: > >> > >> As for the kernel readahead, I have a patchset to increase default > >> mmap read-around size from 128kb to 512kb (except for small memory -> >> systems). This should help your case as well. +> >> systems). A This should help your case as well. > >> > > > > Yes. Is the current readahead really doing read-around(ie does it read pages @@ -39,7 +39,7 @@ On Wed, Apr 07, 2010 at 12:06:07PM +0800, Minchan Kim wrote: > >> > >>>> > >>>> Current Situation: -> >>>> The dynamic linker mmap()s executable and data sections of our +> >>>> The dynamic linker mmap()s A executable and data sections of our > >>>> executable but it doesn't call madvise(). > >>>> By default page faults trigger 131072byte reads. To make matters worse, > >>>> the compile-time linker + gcc lay out code in a manner that does not @@ -80,7 +80,7 @@ On Wed, Apr 07, 2010 at 12:06:07PM +0800, Minchan Kim wrote: > >>>> pressure? Does the kernel simply start ignoring these hints? > >>>> > >>> -> >>> It will throttle based on memory pressure. In idle situations it will +> >>> It will throttle based on memory pressure. A In idle situations it will > >>> eat your file cache, however, to satisfy the request. > >>> > >>> Now, the file cache should be much bigger than the amount of unneeded @@ -89,7 +89,7 @@ On Wed, Apr 07, 2010 at 12:06:07PM +0800, Minchan Kim wrote: > >>> some cache for unused library pages. > >>> > >>> Still, it's a workaround for deficits in the demand-paging/readahead -> >>> heuristics and thus a bit ugly, I feel. Maybe Wu can help. +> >>> heuristics and thus a bit ugly, I feel. A Maybe Wu can help. > >>> > >> > >> Program page faults are inherently random, so the straightforward @@ -112,7 +112,7 @@ On Wed, Apr 07, 2010 at 12:06:07PM +0800, Minchan Kim wrote: > > > > But yes, I completely agree that it would be awesome to increase the > > readahead size proportionally to available memory. It's a little silly to be -> > reading tens of megabytes in 128kb increments :) You rock for trying to +> > reading tens of megabytes in 128kb increments :) A You rock for trying to > > modernize this. > > Hi, Wu and Taras. diff --git a/a/content_digest b/N1/content_digest index 8b20203..1c790b0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -43,7 +43,7 @@ "> >>\n" "> >> As for the kernel readahead, I have a patchset to increase default\n" "> >> mmap read-around size from 128kb to 512kb (except for small memory\n" - "> >> systems). \302\240This should help your case as well.\n" + "> >> systems). A This should help your case as well.\n" "> >>\n" "> >\n" "> > Yes. Is the current readahead really doing read-around(ie does it read pages\n" @@ -54,7 +54,7 @@ "> >>\n" "> >>>>\n" "> >>>> Current Situation:\n" - "> >>>> The dynamic linker mmap()s \302\240executable and data sections of our\n" + "> >>>> The dynamic linker mmap()s A executable and data sections of our\n" "> >>>> executable but it doesn't call madvise().\n" "> >>>> By default page faults trigger 131072byte reads. To make matters worse,\n" "> >>>> the compile-time linker + gcc lay out code in a manner that does not\n" @@ -95,7 +95,7 @@ "> >>>> pressure? Does the kernel simply start ignoring these hints?\n" "> >>>>\n" "> >>>\n" - "> >>> It will throttle based on memory pressure. \302\240In idle situations it will\n" + "> >>> It will throttle based on memory pressure. A In idle situations it will\n" "> >>> eat your file cache, however, to satisfy the request.\n" "> >>>\n" "> >>> Now, the file cache should be much bigger than the amount of unneeded\n" @@ -104,7 +104,7 @@ "> >>> some cache for unused library pages.\n" "> >>>\n" "> >>> Still, it's a workaround for deficits in the demand-paging/readahead\n" - "> >>> heuristics and thus a bit ugly, I feel. \302\240Maybe Wu can help.\n" + "> >>> heuristics and thus a bit ugly, I feel. A Maybe Wu can help.\n" "> >>>\n" "> >>\n" "> >> Program page faults are inherently random, so the straightforward\n" @@ -127,7 +127,7 @@ "> >\n" "> > But yes, I completely agree that it would be awesome to increase the\n" "> > readahead size proportionally to available memory. It's a little silly to be\n" - "> > reading tens of megabytes in 128kb increments :) \302\240You rock for trying to\n" + "> > reading tens of megabytes in 128kb increments :) A You rock for trying to\n" "> > modernize this.\n" "> \n" "> Hi, Wu and Taras.\n" @@ -214,4 +214,4 @@ " \t\tra->start = max_t(long, 0, offset - ra_pages/2);\n" " \t\tra->size = ra_pages;" -ed12e60d5f1f082c454ad51fb71c228cb55ac10b1a053a719b9c291eb831d0cb +ae0595dfc0dfdf17656bac625513ae971f3c74e1668ec6c6f3b5e6034566c9fd
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.