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.
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Stefan Bader (smb)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1319244
Title:
iostat: Cannot open /proc/stat: Cannot allocate memory
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1319244/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
