So define a common maximum size for kmalloc. For conveniences sake
we use the maximum size ever supported which is 32 MB. We limit the maximum
size to a lower limit if MAX_ORDER does not allow such large allocations.
What are the changes a large allocation will actually succeed?
Is there an alignment rule for large allocations?
E.g. for one of the PS3 drivers I need a physically contiguous 256 KiB-aligned
block of 256 KiB. Currently I'm using __alloc_bootmem() for that, but maybe
kmalloc() becomes a suitable alternative now?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
E.g. for one of the PS3 drivers I need a physically contiguous 256
KiB-aligned block of 256 KiB. Currently I'm using __alloc_bootmem()
for that, but maybe kmalloc() becomes a suitable alternative now?
I'm allocating up to 1MB for per-process TLB hash tables
on sparc64. But I can gracefully handle failures and it's
just a performance tweak to use such large sized tables.
From: Christoph Lameter <hidden> Date: 2007-05-16 17:41:59
On Wed, 16 May 2007, Geert Uytterhoeven wrote:
On Tue, 15 May 2007, Christoph Lameter wrote:
quoted
So define a common maximum size for kmalloc. For conveniences sake
we use the maximum size ever supported which is 32 MB. We limit the maximum
size to a lower limit if MAX_ORDER does not allow such large allocations.
What are the changes a large allocation will actually succeed?
Is there an alignment rule for large allocations?
E.g. for one of the PS3 drivers I need a physically contiguous 256 KiB-aligned
block of 256 KiB. Currently I'm using __alloc_bootmem() for that, but maybe
kmalloc() becomes a suitable alternative now?
The chance of succeeding drops with the time that the system has been
running. Typically these large allocs are used when the system is brought
up. Maybe we will be able to successfully allocate these even after
memory has gotten significant use when Mel's antifrag/defrag work has
progressed more.
On Wednesday 16 May 2007, Geert Uytterhoeven wrote:
What are the changes a large allocation will actually succeed?
Is there an alignment rule for large allocations?
E.g. for one of the PS3 drivers I need a physically contiguous 256 KiB-aligned
block of 256 KiB. Currently I'm using __alloc_bootmem() for that, but maybe
kmalloc() becomes a suitable alternative now?
kmalloc is limited to 128KiB on most architectures. Normally there is no
need to use it anyway, just use __get_free_pages(). It will generally
succeed at early boot time, but not after the system has been running
for some time.
Arnd <><
On Wednesday 16 May 2007, Geert Uytterhoeven wrote:
quoted
What are the changes a large allocation will actually succeed?
Is there an alignment rule for large allocations?
E.g. for one of the PS3 drivers I need a physically contiguous 256 KiB-aligned
block of 256 KiB. Currently I'm using __alloc_bootmem() for that, but maybe
kmalloc() becomes a suitable alternative now?
kmalloc is limited to 128KiB on most architectures. Normally there is no
need to use it anyway, just use __get_free_pages(). It will generally
succeed at early boot time, but not after the system has been running
for some time.
Exactly my understanding. And __get_free_pages() returns PAGE_SIZE-aligned
memory. So I'll keep the current code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium