Re: [ofa-general] Re: [ewg] [Patch mthca backport] Don't use kmalloc > 128k
On Jul 27, 2009, at 1:10 PM, Roland Dreier wrote: 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. Right. But does upstream SLAB also pass through to the page allocator the same as SLUB? No, slab just fails, in which case you have to do your own __g_f_p call. How about SLQB? No clue. -- Doug Ledford 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] [Patch mthca backport] Don't use kmalloc > 128k
> > 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. Right. But does upstream SLAB also pass through to the page allocator the same as SLUB? How about SLQB? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] [Patch mthca backport] Don't use kmalloc > 128k
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 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] [Patch mthca backport] Don't use kmalloc > 128k
> 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. And I don't think the upstream kernel has that limit on kmalloc size either (at least with SLUB, not sure about SLAB). Really the long-term fix is to handle non-contiguous memory in the bitmap allocator. maybe using vmalloc(), although I always hate big allocations with vmalloc too. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
