Comment 3 for bug 1319244

It looks like two things at play:
1. Something in the way the system is set up seems to the DMA/DMA32 pool under higher pressure
2. Reading /proc/stat ends up requesting a 64kB memory area (order-4) in the DMA32 pool on node0

While there are still two elements in the 64kB slot, they both are emergency reserve, which open_stat did not ask for. So while there is not much that can easily be done about the memory pressure in general, it looks like open_stat could very well be more conservative about its memory requirement. First the calculation reserves 128 bytes for each possible cpu, while the actual output only produces one line of overall stats, plus one for each online cpu. So it seems to make sense to use the number of online cpus for the allocation. Second the upper limit for the buffer is set to the maximum that kmalloc can do. However it is known that anything beyond order-3 allocations (32kB) are costly and prone to fail due to memory pressure. And having a smaller buffer is not world ending for the stat output either. Since the proc file uses the seq_file functions it only would cause more read calls instead of filling all stats into one single buffer.