[ofa-general] Re: [ewg] [Patch mthca backport] Don't use kmalloc > 128k

[Doug Ledford]

On Jul 23, 2009, at 3:06 PM, Roland Dreier wrote:
>> This will fix the 2^20 bits limit on our bitmaps once and for all.
>
> Not really... since getting > 128KB of contiguous memory is likely to
> fail anyway.

That depends.  If you mean at bootup when you are first loading the  
module, no.  You only need large allocations on large memory boxes,  
and fragmentation won't have happened yet.  So it's a perfectly  
reliable mechanism then.  If you are talking about unloading and  
reloading the module on a busy system, then yes, it could fail then.   
However, I would argue that if you get a module load failure on  
reload, then you could always just reboot (keeping in mind that really  
users shouldn't *need* to ever reload the module anyway, and anything  
that makes them reload the module is probably a bug, I'm perfectly  
happy with saying the bug requires a reboot instead of a module  
reload...that might even provide extra incentive to fix the bug).

> And I don't think the upstream kernel has that limit on kmalloc size
> either (at least with SLUB, not sure about SLAB).

This patch was actually written as an emulation of the upstream SLUB  
behavior, which is exactly the same thing: on large allocations  
forward to __g_f_p().  See include/linux/slub_def.h's definition of  
kmalloc_large and kmalloc.


--

Doug Ledford <dledford at redhat.com>

GPG KeyID: CFBFF194
http://people.redhat.com/dledford

InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090727/7d281cc3/attachment.sig>