[ale] Free is not showing me correct used memory

[Chris Fowler]

I've ran into an issue on a device which runs out of memory, but it refuses to panic on OOM.  This creates a DOS affect.  No SSH to the device, but I am still able to ping it. After reboot messages in syslog show the device has ran out of memory.  Kernel is 2.,6.38 and system is 32bit.

I followed instructions on the URL below to test OOM panic.  I compiled an ran the program to test.  On a system with kernel 5.6.0 the OOM panics and system is restarted.  It works, but on the problem device it is as if the OOM is not fully aware. free, /proc/meminfo, vmstat, etc do not show memory usage skyrocketing as it does on the other system.

Free on the problem device before I run the program:

[root at basement]# free
             total       used       free     shared    buffers cached
Mem:       1964728     235380    1729348          0      12064  55388
-/+ buffers/cache:     167928    1796800
Swap:            0          0          0

Now, I run it and it is able to allocate 82 chunks at 10M each before malloc() failed:

[root at basement]#  oom
Allocated 82 chunks.
Sleeping 60(s) before exiting.

In another xterm I'll run free while oom is waiting to exit.  Once it exits, all that memory is freed. No change.

[root at basement]# free
             total       used       free     shared    buffers cached
Mem:       1964728     236380    1728348          0      12112  55388
-/+ buffers/cache:     168880    1795848
Swap:            0          0          0

If I run oom in another window it will only grab 2 chunks before failure.  Also, watchdog is configured to restart if it can't allocate 20M of memory.  Watchdog will restart the device because it is unable to grab it.

The system itself has 2G of RAM.

If that program was able to allocate 82x10 820M of RAM why did that not show up as used memory?  Now, I'm curious as to why Iw as only able to allocate 830M if there is 1.7GB free?

Below is grep 'MEM' config:

# CONFIG_CGROUP_MEM_RES_CTLR is not set
CONFIG_SHMEM=y
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_DEVKMEM=y
CONFIG_FIX_EARLYCON_MEM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_MEMSTICK is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ASYNC_MEMCPY=y
CONFIG_HAS_IOMEM=y

Also:

CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20200822/b8f88185/attachment.html>