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 <[email protected]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
