Messages in this thread | | | Date | Tue, 14 Jul 2009 14:30:28 -0700 | Subject | Re: [PATCH 3/3] Quick vmalloc vs kmalloc fix to the case where array size is too large | From | Benjamin Blum <> |
| |
Indeed.
Alternatively, I could make it case on KMALLOC_MAX_SIZE as follows:
if (size > KMALLOC_MAX_SIZE) { /* use vmalloc directly */ } else { /* try kmalloc, and, expecting fragmentation, if that fails, use vmalloc */ }
As the free wrapper uses is_vmalloc_addr, it'd work fine and be able to decide for a certain range of sizes whether kmalloc or vmalloc is appropriate.
On Tue, Jul 14, 2009 at 10:50 AM, Paul Menage<menage@google.com> wrote: > On Tue, Jul 14, 2009 at 10:47 AM, Dave Hansen<dave@linux.vnet.ibm.com> wrote: >> >> How big were those allocations that were failing? The code made it >> appear that order-2 (PAGE_SIZE*4) allocations were failing. That's a >> bit lower than I'd expect the page allocator to start failing. > > I think it depends on how much fragmentation you've got. > > We've seen it fail for cpusets with (I guess) hundreds or thousands of threads. > > Paul > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |