Questton about Zone Allocation 2.4.X
LKML,
I have a system in the lab with 4GB of physical and the system can see all the memory, however, calls to get_free_pages() will only allocate up to 1GB of this memory before returning an out of memory condition. I have reviewed Ingo's changes and enhancements with the zone allocator and it certainly looks like this code has the smarts to balance the contiguous free pages on the zone allocation lists. I need to be able to get more than 1GB to pin for a particular application. Where do I need to adjust the tuning to allow 2.4.X kernels to allocate mote than 1GB from the physical pages list?
Any help would be appreciated.
Thanks
Jeff Merkey
Network Associates
Quoted 5 lines · Jeff V. Merkey
I have a system in the lab with 4GB of physical and the system can see all the memory, however, calls to
get_free_pages()will only allocate up to 1GB of this memory before returning an out of memory condition. I have reviewed Ingo's changes and enhancements with the zone allocator and it certainly looks like this code has the smarts to balance the contiguous free pages
Quoted 8 lines
on the zone allocation lists. I need to be able to get more than 1GB to pin for a particular application. Where do I need to adjust the tuning to allow 2.4.X kernels to allocate mote than 1GB from the physical pages list?
Any help would be appreciated.
Thanks
Jeff Merkey
Network Associates
__get_free_pages() allocates from lowmem (i.e. 0-4GB) only. Allocate from highmem instead.
Bill
Quoted 2 lines · William Lee Irwin III
__get_free_pages()allocates from lowmem (i.e. 0-4GB) only. Allocate from highmem instead.
0-1GB only.
Bill
Quoted 4 lines
__get_free_pages()allocates from lowmem (i.e. 0-4GB) only. Allocate from highmem instead.
0-4GB is where I need to allocate, so allocating from highmem is not a solution. I found the Ingo/Andrea patch for RH 8.0, but this patch looks a little scary since it affects the memory allocations between user and kernel space and the ratios alloted to these areas (I may be missing something here -- as Dave M. puts it "Jeff you are such a pain in the ass sometimes" :-).
Jeff
Quoted 3 lines
Bill
Quoted 2 lines · At some point in the past, I wrote:
Quoted 2 lines
__get_free_pages()allocates from lowmem (i.e. 0-4GB) only. Allocate from highmem instead.
0-1GB. page_address() will give unpredictable results on highmem GFP masks.
Quoted 6 lines · Jeff V. Merkey
0-4GB is where I need to allocate, so allocating from highmem is not a solution. I found the Ingo/Andrea patch for RH 8.0, but this patch looks a little scary since it affects the memory allocations between user and kernel space and the ratios alloted to these areas (I may be missing something here -- as Dave M. puts it "Jeff you are such a pain in the ass sometimes" :-).
There is no GFP mask for it. Port Jens' ZONE_DMA32 or something, or roll ZONE_4G on your own if need be.
Bill
Re: Question about Zone Allocation 2.4.X
Quoted 5 lines · William Lee Irwin III
Quoted 2 lines · At some point in the past, I wrote:
Quoted 2 lines
__get_free_pages()allocates from lowmem (i.e. 0-4GB) only. Allocate from highmem instead.0-1GB.
page_address()will give unpredictable results on highmem GFP masks.
Sounds broken to me.
Quoted 3 lines
There is no GFP mask for it. Port Jens'
ZONE_DMA32or something, or rollZONE_4Gon your own if need be.
Bill,
Looks like we simply jetisioned the concept of a PPL (Physical Pages List)
and went with a zone allocator instead. I'm sure there was a good reason for
it historically. Rolling a separate zone is exactly what I was thinking
when I reviewed the code intially. Question, which files will be affected so when I put this one in, I don't end up breaking the VM and userspace balancing logic. i.e. Could you point me to Jens' ZONE_DMA32 code as well.
Thanks
Jeff
Quoted 3 lines
Bill
Re: Question about Zone Allocation 2.4.X
Quoted 7 lines · Jeff V. Merkey
Looks like we simply jetisioned the concept of a PPL (Physical Pages List) and went with a zone allocator instead. I'm sure there was a good reason for it historically. Rolling a separate zone is exactly what I was thinking when I reviewed the code intially. Question, which files will be affected so when I put this one in, I don't end up breaking the VM and userspace balancing logic. i.e. Could you point me to Jens'
ZONE_DMA32code as well.
Adding new zone types is easy. Just add them to mmzone.h, avoid setting ->virtual (which does not universally exist) in free_area_init_core() if it's not perma-mapped, stuff them in the fallback sequence in build_zonelists(), and detect them in arch/*/mm/init.c
Bill
Re: Question about Zone Allocation 2.4.X
Quoted 6 lines · William Lee Irwin III
Adding new zone types is easy. Just add them to
mmzone.h, avoid setting ->virtual (which does not universally exist) infree_area_init_core()if it's not perma-mapped, stuff them in the fallback sequence inbuild_zonelists(), and detect them inarch/*/mm/init.c
Bill,
I also just reviewed the changes to the mmu code mode by Ingo -- very ugly stuff. Looks like both changes are required to get this working properly since without the PDE being setup properly, we'll get page faults since the AS above 1GB is not mapped by the mmu.
Jeff
Quoted 7 lines
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Zone Allocation 2.4.X
Quoted 4 lines · William Lee Irwin III
Quoted 4 lines
Adding new zone types is easy. Just add them to
mmzone.h, avoid setting ->virtual (which does not universally exist) infree_area_init_core()if it's not perma-mapped, stuff them in the fallback sequence inbuild_zonelists(), and detect them inarch/*/mm/init.c
Quoted 4 lines · Jeff V. Merkey
I also just reviewed the changes to the mmu code mode by Ingo -- very ugly stuff. Looks like both changes are required to get this working properly since without the PDE being setup properly, we'll get page faults since the AS above 1GB is not mapped by the mmu.
Not a big deal. Just kmap()/kunmap() or kmap_atomic()/kunmap_atomic() as needed. Physical address extensions and this kind of windowing has been around long enough to just be "there", not ugly, pretty, or interesting. It should all be well enough understood these days that either myself or a few dozen others could help there.
Bill