Re: Slab allocators: Define common size limitations

Re: Slab allocators: Define common size limitations

[Geert Uytterhoeven]

On Tue, 15 May 2007, Christoph Lameter wrote:
> 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

Re: Slab allocators: Define common size limitations

[David Miller]

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date: Wed, 16 May 2007 08:58:39 +0200 (CEST)

> 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.

Re: Slab allocators: Define common size limitations

[Christoph Lameter]

On Wed, 16 May 2007, Geert Uytterhoeven wrote:

> On Tue, 15 May 2007, Christoph Lameter wrote:
> > 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.

Re: Slab allocators: Define common size limitations

[Arnd Bergmann]

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 <><

Re: Slab allocators: Define common size limitations

[Geert Uytterhoeven]

On Wed, 16 May 2007, Arnd Bergmann wrote:
> 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.

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