diff for duplicates of <m1iteegag6.fsf@frodo.biederman.org> diff --git a/a/1.txt b/N1/1.txt index e42bb50..0eb8864 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,11 +5,11 @@ Alan Cox <alan@lxorguk.ukuu.org.uk> writes: > > > to make the common case fast at the expense of making it more > > > difficult to handle times when the VM system is under extreme load and > > > we are swapping etc. -> > +> > > > What do you suppose is the cost of the reverse map? I get the impression you -> +> > > think it's more expensive than it is. -> +> > We can keep the typical page table cost lower than now (including reverse > maps) just by doing some common sense small cleanups to get the page struct > down to 48 bytes on x86 @@ -19,12 +19,12 @@ was much lighter weight, then now (64 bytes x86 UP). And our cost per page was noticeably fewer bytes than the BSDs. average_mem_per_page = sizeof(struct page) + sizeof(pte_t) + sizeof(reverse_pte_t)*average_user_per_page. But struct page has grown pretty significantly since then, and could -use a cleanup. +use a cleanup. So I figure it is worth going through and computing the costs of reverse page tables and not, dismissing them out of hand. But the fact that the linux VM could get good performance in most -circumstances without reverse page tables has always enchanted me. +circumstances without reverse page tables has always enchanted me. That added to the fact that last time someone ran the numbers linux was considerably faster than the BSD for mm type operations when not @@ -64,3 +64,10 @@ So right now I can see a bigger benefit from anonymouse pages with a ``backing store'' then I can from reverse maps. Eric + + + +-- +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/ diff --git a/a/content_digest b/N1/content_digest index 31e506f..92c85ce 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,8 +3,8 @@ "Subject\0Re: broken VM in 2.4.10-pre9\0" "Date\019 Sep 2001 15:03:21 -0600\0" "To\0Alan Cox <alan@lxorguk.ukuu.org.uk>\0" - "Cc\0phillips@bonn-fries.net (Daniel Phillips)" - rfuller@nsisoftware.com (Rob Fuller) + "Cc\0Daniel Phillips <phillips@bonn-fries.net>" + Rob Fuller <rfuller@nsisoftware.com> linux-kernel@vger.kernel.org " linux-mm@kvack.org\0" "\00:1\0" @@ -16,11 +16,11 @@ "> > > to make the common case fast at the expense of making it more\n" "> > > difficult to handle times when the VM system is under extreme load and\n" "> > > we are swapping etc.\n" - "> > \n" + "> >\n" "> > What do you suppose is the cost of the reverse map? I get the impression you\n" - "> \n" + ">\n" "> > think it's more expensive than it is.\n" - "> \n" + ">\n" "> We can keep the typical page table cost lower than now (including reverse\n" "> maps) just by doing some common sense small cleanups to get the page struct\n" "> down to 48 bytes on x86\n" @@ -30,12 +30,12 @@ "page was noticeably fewer bytes than the BSDs. average_mem_per_page =\n" "sizeof(struct page) + sizeof(pte_t) + sizeof(reverse_pte_t)*average_user_per_page.\n" "But struct page has grown pretty significantly since then, and could\n" - "use a cleanup. \n" + "use a cleanup.\n" "\n" "So I figure it is worth going through and computing the costs of\n" "reverse page tables and not, dismissing them out of hand. But the\n" "fact that the linux VM could get good performance in most\n" - "circumstances without reverse page tables has always enchanted me. \n" + "circumstances without reverse page tables has always enchanted me.\n" "\n" "That added to the fact that last time someone ran the numbers linux\n" "was considerably faster than the BSD for mm type operations when not\n" @@ -74,6 +74,13 @@ "So right now I can see a bigger benefit from anonymouse pages with a\n" "``backing store'' then I can from reverse maps.\n" "\n" - Eric + "Eric\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/ -a74054dfe6640afbae84d7aba097eb1336f95795a67a2174dee8a00460a107bd +b2f976faefcc4294709f7b7dae71058c2e581fb68e8d263af47363ef6032fc58
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.