Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)

2007-03-21 Thread Christoph Hellwig
On Wed, Mar 21, 2007 at 03:55:54PM +, Hugh Dickins wrote: > On Mon, 19 Mar 2007, Adam Litke wrote: > > Andrew, given the favorable review of these patches the last time around, > > would > > you consider them for the -mm tree? Does anyone else have any objections? > > I quite fail to underst

Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)

2007-03-21 Thread Hugh Dickins
On Mon, 19 Mar 2007, Adam Litke wrote: > Andrew, given the favorable review of these patches the last time around, > would > you consider them for the -mm tree? Does anyone else have any objections? I quite fail to understand the enthusiasm for these patches. All they do is make the already ugl

Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)

2007-03-20 Thread William Lee Irwin III
On Mon, Mar 19, 2007 at 01:05:02PM -0700, Adam Litke wrote: > Andrew, given the favorable review of these patches the last time > around, would you consider them for the -mm tree? Does anyone else > have any objections? We need a new round of commentary for how it should integrate with Nick Piggi

Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)

2007-03-20 Thread Dave Hansen
On Mon, 2007-03-19 at 13:05 -0700, Adam Litke wrote: > For the common case (vma->pagetable_ops == NULL), we do almost the > same thing as the current code: load and test. The third instruction > is different in that we jump for the common case instead of jumping in > the hugetlb case. I don't thi

[PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)

2007-03-19 Thread Adam Litke
Andrew, given the favorable review of these patches the last time around, would you consider them for the -mm tree? Does anyone else have any objections? The page tables for hugetlb mappings are handled differently than page tables for normal pages. Rather than integrating multiple page size su