Moments ago, I said: > > oom-killer: gfp_mask=0x40d0, order=9 [...] > Trying to allocate a further 1MB must therefore split the 2MB block in > half (since there's no VMM it's not possible to stitch smaller blocks > together). > > In any case, allocating 1024KB from the 3040KB free would leave 2016KB.
Actually, come to think of it, an order 9 allocation is 2MB, not 1MB. (2^9 pages * 4KB per page.) So you're actually going to be left with 992KB free, which is definitely below the reserved limit. This is probably happening because there's a bit of housekeeping information attached to each memory allocation by either the kernel or the libc. This will increase the required allocation size slightly, and since page allocations must always be a power of two this is kicking it up to the next notch (and doubling the actual allocation). On my particular setup this allocation overhead is about 8 bytes, but it might be different on yours. _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
