From: Christoph Hellwig <hch@infradead.org> To: Mel Gorman <mel@skynet.ie> Cc: Christoph Hellwig <hch@infradead.org>, Adam Litke <agl@us.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, Arjan van de Ven <arjan@infradead.org>, William Lee Irwin III <wli@holomorphy.com>, Ken Chen <kenchen@google.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: pagetable_ops: Hugetlb character device example Date: Thu, 22 Mar 2007 18:15:37 +0000 [thread overview] Message-ID: <20070322181537.GA8317@infradead.org> (raw) In-Reply-To: <20070322154227.GA14366@skynet.ie> On Thu, Mar 22, 2007 at 03:42:27PM +0000, Mel Gorman wrote: > A year ago, I may have agreed with you. However, Linus not only veto'd it but > stamped on it repeatadly at VM Summit. He couldn't have made it clearer if > he wore a t-shirt a hat and held up a neon sign. The assertion at the time > was that variable page support of any sort had to be outside of the core VM > because automatic support will get it wrong in some cases and makes the core > VM harder to understand (because it's super-clear at the moment). Others > attending agreed with the position. That position rules out drivers or > filesystems giving hints about superpage sizes in the foreseeable future. Actually I think the only way to get it right is to do it in the core (or inm the architecture code for the really nasty bits of course), but then again this isn't the point I want to make here.. > What they did not have any problem with was providing better interfaces to > program against as long as they were on the side of the VM like hugetlbfs > and not in the core. The character device for private mappings is an > example of an interface that is easier to program against than hugetlbfs. > It's far easier for an application to mmap a file at a fixed location than > trying to discover if hugetlbfs is mounted or not. However, to support that > sort of interface, there needs to be a way of telling the VM to call the an > alternative pagetable handler - hence Adam's patches. .. and this is where we get into problems. There should be no need to use all kinds of pseudo-OO obsfucation to get there. A VMA flag that means 'this is hugetlb backed anonymous memory' is much nicer to archive this. Because it makes clear there is exactly one special case here and no carte blanche for drivers to do whatever they want. I would prefer to even get rid of that single special case as mentioned above, but I'm definitly set dead against at making this special case totally open for random bits of the kernel to mess with. > Someone with sufficient energy could try implementing variable page support > entirely as a device using Adam's interface. Hopefully not, doing this in a driver would be utterly braindead and certainly not mergeable.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Mel Gorman <mel@skynet.ie> Cc: Christoph Hellwig <hch@infradead.org>, Adam Litke <agl@us.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, Arjan van de Ven <arjan@infradead.org>, William Lee Irwin III <wli@holomorphy.com>, Ken Chen <kenchen@google.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: pagetable_ops: Hugetlb character device example Date: Thu, 22 Mar 2007 18:15:37 +0000 [thread overview] Message-ID: <20070322181537.GA8317@infradead.org> (raw) In-Reply-To: <20070322154227.GA14366@skynet.ie> On Thu, Mar 22, 2007 at 03:42:27PM +0000, Mel Gorman wrote: > A year ago, I may have agreed with you. However, Linus not only veto'd it but > stamped on it repeatadly at VM Summit. He couldn't have made it clearer if > he wore a t-shirt a hat and held up a neon sign. The assertion at the time > was that variable page support of any sort had to be outside of the core VM > because automatic support will get it wrong in some cases and makes the core > VM harder to understand (because it's super-clear at the moment). Others > attending agreed with the position. That position rules out drivers or > filesystems giving hints about superpage sizes in the foreseeable future. Actually I think the only way to get it right is to do it in the core (or inm the architecture code for the really nasty bits of course), but then again this isn't the point I want to make here.. > What they did not have any problem with was providing better interfaces to > program against as long as they were on the side of the VM like hugetlbfs > and not in the core. The character device for private mappings is an > example of an interface that is easier to program against than hugetlbfs. > It's far easier for an application to mmap a file at a fixed location than > trying to discover if hugetlbfs is mounted or not. However, to support that > sort of interface, there needs to be a way of telling the VM to call the an > alternative pagetable handler - hence Adam's patches. .. and this is where we get into problems. There should be no need to use all kinds of pseudo-OO obsfucation to get there. A VMA flag that means 'this is hugetlb backed anonymous memory' is much nicer to archive this. Because it makes clear there is exactly one special case here and no carte blanche for drivers to do whatever they want. I would prefer to even get rid of that single special case as mentioned above, but I'm definitly set dead against at making this special case totally open for random bits of the kernel to mess with. > Someone with sufficient energy could try implementing variable page support > entirely as a device using Adam's interface. Hopefully not, doing this in a driver would be utterly braindead and certainly not mergeable. -- 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 prev parent reply other threads:[~2007-03-22 18:16 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-03-19 20:05 [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2) Adam Litke 2007-03-19 20:05 ` Adam Litke 2007-03-19 20:05 ` [PATCH 1/7] Introduce the pagetable_operations and associated helper macros Adam Litke 2007-03-19 20:05 ` Adam Litke 2007-03-20 23:24 ` Dave Hansen 2007-03-20 23:24 ` Dave Hansen 2007-03-21 14:50 ` Adam Litke 2007-03-21 14:50 ` Adam Litke 2007-03-21 15:05 ` Arjan van de Ven 2007-03-21 15:05 ` Arjan van de Ven 2007-03-21 4:18 ` Nick Piggin 2007-03-21 4:18 ` Nick Piggin 2007-03-21 4:52 ` William Lee Irwin III 2007-03-21 4:52 ` William Lee Irwin III 2007-03-21 5:07 ` Nick Piggin 2007-03-21 5:07 ` Nick Piggin 2007-03-21 5:41 ` William Lee Irwin III 2007-03-21 5:41 ` William Lee Irwin III 2007-03-21 6:51 ` Nick Piggin 2007-03-21 6:51 ` Nick Piggin 2007-03-21 7:36 ` Nick Piggin 2007-03-21 7:36 ` Nick Piggin 2007-03-21 10:46 ` William Lee Irwin III 2007-03-21 10:46 ` William Lee Irwin III 2007-03-21 15:17 ` Adam Litke 2007-03-21 15:17 ` Adam Litke 2007-03-21 16:00 ` Christoph Hellwig 2007-03-21 16:00 ` Christoph Hellwig 2007-03-21 23:03 ` Nick Piggin 2007-03-21 23:03 ` Nick Piggin 2007-03-21 23:02 ` Nick Piggin 2007-03-21 23:02 ` Nick Piggin 2007-03-21 23:32 ` William Lee Irwin III 2007-03-21 23:32 ` William Lee Irwin III 2007-03-19 20:05 ` [PATCH 2/7] copy_vma for hugetlbfs Adam Litke 2007-03-19 20:05 ` Adam Litke 2007-03-19 20:05 ` [PATCH 3/7] pin_pages for hugetlb Adam Litke 2007-03-19 20:05 ` Adam Litke 2007-03-19 20:05 ` [PATCH 4/7] unmap_page_range " Adam Litke 2007-03-19 20:05 ` Adam Litke 2007-03-20 23:27 ` Dave Hansen 2007-03-20 23:27 ` Dave Hansen 2007-03-19 20:05 ` [PATCH 5/7] change_protection " Adam Litke 2007-03-19 20:05 ` Adam Litke 2007-03-19 20:06 ` [PATCH 6/7] free_pgtable_range " Adam Litke 2007-03-19 20:06 ` Adam Litke 2007-03-19 20:06 ` [PATCH 7/7] hugetlbfs fault handler Adam Litke 2007-03-19 20:06 ` Adam Litke 2007-03-20 23:50 ` [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2) Dave Hansen 2007-03-20 23:50 ` Dave Hansen 2007-03-21 1:17 ` William Lee Irwin III 2007-03-21 1:17 ` William Lee Irwin III 2007-03-21 15:55 ` Hugh Dickins 2007-03-21 15:55 ` Hugh Dickins 2007-03-21 16:01 ` Christoph Hellwig 2007-03-21 16:01 ` Christoph Hellwig 2007-03-21 16:23 ` William Lee Irwin III 2007-03-21 17:08 ` Hugh Dickins 2007-03-21 17:42 ` William Lee Irwin III 2007-03-21 19:43 ` pagetable_ops: Hugetlb character device example Adam Litke 2007-03-21 19:43 ` Adam Litke 2007-03-21 19:51 ` Valdis.Kletnieks 2007-03-21 20:26 ` Adam Litke 2007-03-21 20:26 ` Adam Litke 2007-03-21 22:26 ` William Lee Irwin III 2007-03-21 22:26 ` William Lee Irwin III 2007-03-21 22:53 ` Matt Mackall 2007-03-21 22:53 ` Matt Mackall 2007-03-21 23:35 ` William Lee Irwin III 2007-03-21 23:35 ` William Lee Irwin III 2007-03-22 0:31 ` Matt Mackall 2007-03-22 0:31 ` Matt Mackall 2007-03-22 10:38 ` Christoph Hellwig 2007-03-22 10:38 ` Christoph Hellwig 2007-03-22 15:42 ` Mel Gorman 2007-03-22 15:42 ` Mel Gorman 2007-03-22 18:15 ` Christoph Hellwig [this message] 2007-03-22 18:15 ` Christoph Hellwig 2007-03-23 14:57 ` Mel Gorman 2007-03-23 14:57 ` Mel Gorman
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=20070322181537.GA8317@infradead.org \ --to=hch@infradead.org \ --cc=agl@us.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=arjan@infradead.org \ --cc=kenchen@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@skynet.ie \ --cc=wli@holomorphy.com \ /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.