From: Adam Litke <agl@us.ibm.com> To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, agl@us.ibm.com Subject: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Date: Mon, 19 Feb 2007 10:31:23 -0800 [thread overview] Message-ID: <20070219183123.27318.27319.stgit@localhost.localdomain> (raw) The page tables for hugetlb mappings are handled differently than page tables for normal pages. Rather than integrating multiple page size support into the main VM (which would tremendously complicate the code) some hooks were created. This allows hugetlb special cases to be handled "out of line" by a separate interface. Hugetlbfs was the huge page interface chosen. At the time, large database users were the only big users of huge pages and the hugetlbfs design meets their needs pretty well. Over time, hugetlbfs has been expanded to enable new uses of huge page memory with varied results. As features are added, the semantics become a permanent part of the Linux API. This makes maintenance of hugetlbfs an increasingly difficult task and inhibits the addition of features and functionality in support of ever-changing hardware. To remedy the situation, I propose an API (currently called pagetable_operations). All of the current hugetlbfs-specific hooks are moved into an operations struct that is attached to VMAs. The end result is a more explicit and IMO a cleaner interface between hugetlbfs and the core VM. We are then free to add other hugetlb interfaces (such as a /dev/zero-styled character device) that can operate either in concert with or independent of hugetlbfs. There should be no measurable performance impact for normal page users (we're checking if pagetable_ops != NULL instead of checking for vm_flags & VM_HUGETLB). Of course we do increase the VMA size by one pointer. For huge pages, there is an added indirection for pt_op() calls. This patch series does not change the logic of the the hugetlbfs operations, just moves them into the pagetable_operations struct. Comments? Do you think it's as good of an idea as I do?
WARNING: multiple messages have this Message-ID (diff)
From: Adam Litke <agl@us.ibm.com> To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, agl@us.ibm.com Subject: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Date: Mon, 19 Feb 2007 10:31:23 -0800 [thread overview] Message-ID: <20070219183123.27318.27319.stgit@localhost.localdomain> (raw) The page tables for hugetlb mappings are handled differently than page tables for normal pages. Rather than integrating multiple page size support into the main VM (which would tremendously complicate the code) some hooks were created. This allows hugetlb special cases to be handled "out of line" by a separate interface. Hugetlbfs was the huge page interface chosen. At the time, large database users were the only big users of huge pages and the hugetlbfs design meets their needs pretty well. Over time, hugetlbfs has been expanded to enable new uses of huge page memory with varied results. As features are added, the semantics become a permanent part of the Linux API. This makes maintenance of hugetlbfs an increasingly difficult task and inhibits the addition of features and functionality in support of ever-changing hardware. To remedy the situation, I propose an API (currently called pagetable_operations). All of the current hugetlbfs-specific hooks are moved into an operations struct that is attached to VMAs. The end result is a more explicit and IMO a cleaner interface between hugetlbfs and the core VM. We are then free to add other hugetlb interfaces (such as a /dev/zero-styled character device) that can operate either in concert with or independent of hugetlbfs. There should be no measurable performance impact for normal page users (we're checking if pagetable_ops != NULL instead of checking for vm_flags & VM_HUGETLB). Of course we do increase the VMA size by one pointer. For huge pages, there is an added indirection for pt_op() calls. This patch series does not change the logic of the the hugetlbfs operations, just moves them into the pagetable_operations struct. Comments? Do you think it's as good of an idea as I do? -- 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>
next reply other threads:[~2007-02-19 18:31 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-19 18:31 Adam Litke [this message] 2007-02-19 18:31 ` [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Adam Litke 2007-02-19 18:31 ` [PATCH 1/7] Introduce the pagetable_operations and associated helper macros Adam Litke 2007-02-19 18:31 ` Adam Litke 2007-02-19 18:41 ` Arjan van de Ven 2007-02-19 18:41 ` Arjan van de Ven 2007-02-19 19:31 ` Adam Litke 2007-02-19 19:31 ` Adam Litke 2007-02-19 19:48 ` William Lee Irwin III 2007-02-19 19:48 ` William Lee Irwin III 2007-02-19 22:29 ` Christoph Hellwig 2007-02-19 22:29 ` Christoph Hellwig 2007-02-20 15:50 ` Mel Gorman 2007-02-20 15:50 ` Mel Gorman 2007-02-19 18:31 ` [PATCH 2/7] copy_vma for hugetlbfs Adam Litke 2007-02-19 18:31 ` Adam Litke 2007-02-19 18:31 ` [PATCH 3/7] pin_pages for hugetlb Adam Litke 2007-02-19 18:31 ` Adam Litke 2007-02-19 18:32 ` [PATCH 4/7] unmap_page_range " Adam Litke 2007-02-19 18:32 ` Adam Litke 2007-02-19 18:32 ` [PATCH 5/7] change_protection " Adam Litke 2007-02-19 18:32 ` Adam Litke 2007-02-19 18:32 ` [PATCH 6/7] free_pgtable_range " Adam Litke 2007-02-19 18:32 ` Adam Litke 2007-02-19 18:32 ` [PATCH 7/7] hugetlbfs fault handler Adam Litke 2007-02-19 18:32 ` Adam Litke 2007-02-19 18:43 ` [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Arjan van de Ven 2007-02-19 18:43 ` Arjan van de Ven 2007-02-19 19:34 ` Adam Litke 2007-02-19 19:34 ` Adam Litke 2007-02-19 21:15 ` Arjan van de Ven 2007-02-19 21:15 ` Arjan van de Ven 2007-02-20 19:57 ` Benjamin Herrenschmidt 2007-02-20 19:57 ` Benjamin Herrenschmidt 2007-02-20 19:54 ` Benjamin Herrenschmidt 2007-02-20 19:54 ` Benjamin Herrenschmidt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070219183123.27318.27319.stgit@localhost.localdomain \ --to=agl@us.ibm.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.