diff for duplicates of <20100407074732.GC17892@localhost> diff --git a/a/1.txt b/N1/1.txt index 3739df2..6f70909 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -30,7 +30,7 @@ On Wed, Apr 07, 2010 at 03:33:52PM +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 @@ -41,7 +41,7 @@ On Wed, Apr 07, 2010 at 03:33:52PM +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 @@ -82,7 +82,7 @@ On Wed, Apr 07, 2010 at 03:33:52PM +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 @@ -91,7 +91,7 @@ On Wed, Apr 07, 2010 at 03:33:52PM +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 @@ -114,7 +114,7 @@ On Wed, Apr 07, 2010 at 03:33:52PM +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. @@ -176,3 +176,9 @@ from large readahead", then we can do some static assignment. 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/ . +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 24e1961..1afdf6f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -47,7 +47,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" @@ -58,7 +58,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" @@ -99,7 +99,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" @@ -108,7 +108,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" @@ -131,7 +131,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" @@ -192,6 +192,12 @@ "from large readahead\", then we can do some static assignment.\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" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -671aa6c185eddae6be0563db060f9acb0e15c2b67b6714247ed3db74d2ed21fe +ace2f36b5e7cd083f72968e66d321206c7980689a43cbf81746d3e9385581fa9
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.