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
On Thu, Jan 02, 2003 at 05:55:17PM -0700, Jeff V. Merkey wrote:
> 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
__get_free_pages() allocates from lowmem (i.e. 0-4GB) only.
Allocate from highmem instead.
Bill
On Thu, Jan 02, 2003 at 03:51:47PM -0800, William Lee Irwin III wrote:
> __get_free_pages() allocates from lowmem (i.e. 0-4GB) only.
> Allocate from highmem instead.
0-1GB only.
Bill
At some point in the past, I wrote:
>> __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.
On Thu, Jan 02, 2003 at 06:08:49PM -0700, Jeff V. Merkey wrote:
> 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
On Thu, Jan 02, 2003 at 04:00:34PM -0800, William Lee Irwin III wrote:
> At some point in the past, I wrote:
> >> __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.
>
> There is no GFP mask for it. Port Jens' ZONE_DMA32 or something, or roll
> ZONE_4G on 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
>
>
> Bill
>
> __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
>
>
> Bill
On Thu, Jan 02, 2003 at 06:15:54PM -0700, Jeff V. Merkey wrote:
> 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.
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
On Thu, Jan 02, 2003 at 04:11:27PM -0800, William Lee Irwin III wrote:
>
> 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,
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
>
> 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/
On Thu, Jan 02, 2003 at 04:11:27PM -0800, William Lee Irwin III wrote:
>> 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
On Thu, Jan 02, 2003 at 06:32:18PM -0700, Jeff V. Merkey wrote:
> 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