On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> Probably just terminological disagreement here. I was referring to
>> allocating the higher-order page from the fault path here, not mapping
>> it or a piece of it with a user pte.
On Fri, Apr 20, 2007 at 10:57:25AM -0700, Christoph Lameter
Some ideas for memory.c pieces. Just junk like the earlier patches.
---
mm/memory.c | 108
1 file changed, 66 insertions(+), 42 deletions(-)
Index: linux-2.6.21-rc7/mm/memory.c
Variable Order Page Cache: Readahead fixups
Readahead is now dependent on the page size. For larger page sizes
we want less readahead.
Add a parameter to max_sane_readahead specifying the page order
and update the code in mm/readahead.c to be aware of variant
page sizes.
[WARNING untested
Variable Order Page Cache: mmap_nopage and mmap_populate
Fix up both functions to be able to operate on arbitrary order
pages. However, both functions establish page table entries
in PAGE_SIZE only and the offset and pgoffset when calling
both functions is always in PAGE_SIZE units. Thus the
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
> On Fri, 20 Apr 2007, William Lee Irwin III wrote:
> >> The core VM can do that but the hugetlb architectural code can't fall
> >> back to smaller page sizes. It also should not be put into a situation
> >> where it needs to do so given the
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> The core VM can do that but the hugetlb architectural code can't fall
>> back to smaller page sizes. It also should not be put into a situation
>> where it needs to do so given the semantics it must honor.
On Fri, Apr 20, 2007 at 10:15:00AM
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>
> On Fri, Apr 20, 2007 at 09:30:30AM -0700, Christoph Lameter wrote:
> > We can map arbitrary 4k chunks of larger pages.
>
> The core VM can do that but the hugetlb architectural code can't fall
> back to smaller page sizes. It also should not
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
>> Careful there. mmap() needs more than this.
>> (1) mapping->order is variable within an fs, so the architectural code
>> would need some vague awareness of the underlying page size
>> being variable unless the fs restricts it properly.
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
> On Fri, Apr 20, 2007 at 02:42:27PM +0100, Mel Gorman wrote:
> > That's fair enough for the moment but relaxing would make ramfs
> > potentially usable as a replacement for hugetlbfs so there would be just
> > one ram-based filesystem instead of
On Fri, 20 Apr 2007, Mel Gorman wrote:
> So the difference here appears to be that specifying an order means you
> can't mmap(). right?
>
> That's fair enough for the moment but relaxing would make ramfs
> potentially usable as a replacement for hugetlbfs so there would be just
> one ram-based
On Fri, Apr 20, 2007 at 02:42:27PM +0100, Mel Gorman wrote:
> That's fair enough for the moment but relaxing would make ramfs
> potentially usable as a replacement for hugetlbfs so there would be just
> one ram-based filesystem instead of two.
Careful there. mmap() needs more than this.
(1)
On (19/04/07 09:35), Christoph Lameter didst pronounce:
> Variable Order Page Cache: Add support to ramfs
>
> The simplest file system to use is ramfs. Add a mount parameter that
> specifies the page order of the pages that ramfs should use. If the
> order is greater than zero then disable mmap
On (19/04/07 09:35), Christoph Lameter didst pronounce:
Variable Order Page Cache: Add support to ramfs
The simplest file system to use is ramfs. Add a mount parameter that
specifies the page order of the pages that ramfs should use. If the
order is greater than zero then disable mmap
On Fri, Apr 20, 2007 at 02:42:27PM +0100, Mel Gorman wrote:
That's fair enough for the moment but relaxing would make ramfs
potentially usable as a replacement for hugetlbfs so there would be just
one ram-based filesystem instead of two.
Careful there. mmap() needs more than this.
(1)
On Fri, 20 Apr 2007, Mel Gorman wrote:
So the difference here appears to be that specifying an order means you
can't mmap(). right?
That's fair enough for the moment but relaxing would make ramfs
potentially usable as a replacement for hugetlbfs so there would be just
one ram-based
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Fri, Apr 20, 2007 at 02:42:27PM +0100, Mel Gorman wrote:
That's fair enough for the moment but relaxing would make ramfs
potentially usable as a replacement for hugetlbfs so there would be just
one ram-based filesystem instead of two.
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
Careful there. mmap() needs more than this.
(1) mapping-order is variable within an fs, so the architectural code
would need some vague awareness of the underlying page size
being variable unless the fs restricts it properly.
On Fri,
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Fri, Apr 20, 2007 at 09:30:30AM -0700, Christoph Lameter wrote:
We can map arbitrary 4k chunks of larger pages.
The core VM can do that but the hugetlb architectural code can't fall
back to smaller page sizes. It also should not be put
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
The core VM can do that but the hugetlb architectural code can't fall
back to smaller page sizes. It also should not be put into a situation
where it needs to do so given the semantics it must honor.
On Fri, Apr 20, 2007 at 10:15:00AM -0700,
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
The core VM can do that but the hugetlb architectural code can't fall
back to smaller page sizes. It also should not be put into a situation
where it needs to do so given the semantics it
Variable Order Page Cache: Readahead fixups
Readahead is now dependent on the page size. For larger page sizes
we want less readahead.
Add a parameter to max_sane_readahead specifying the page order
and update the code in mm/readahead.c to be aware of variant
page sizes.
[WARNING untested
Variable Order Page Cache: mmap_nopage and mmap_populate
Fix up both functions to be able to operate on arbitrary order
pages. However, both functions establish page table entries
in PAGE_SIZE only and the offset and pgoffset when calling
both functions is always in PAGE_SIZE units. Thus the
Some ideas for memory.c pieces. Just junk like the earlier patches.
---
mm/memory.c | 108
1 file changed, 66 insertions(+), 42 deletions(-)
Index: linux-2.6.21-rc7/mm/memory.c
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
Probably just terminological disagreement here. I was referring to
allocating the higher-order page from the fault path here, not mapping
it or a piece of it with a user pte.
On Fri, Apr 20, 2007 at 10:57:25AM -0700, Christoph Lameter wrote:
Variable Order Page Cache: Add support to ramfs
The simplest file system to use is ramfs. Add a mount parameter that
specifies the page order of the pages that ramfs should use. If the
order is greater than zero then disable mmap functionality.
This could be removed if the VM would be changes to
Variable Order Page Cache: Add support to ramfs
The simplest file system to use is ramfs. Add a mount parameter that
specifies the page order of the pages that ramfs should use. If the
order is greater than zero then disable mmap functionality.
This could be removed if the VM would be changes to
26 matches
Mail list logo
