How to find how much userspace memory available to use in Linux environment?

Question

I am using CONFIG_VMSPLIT_1G config in my 32-bit Linux image. so 3GB of virtual address space is allocated to kernel and 1GB of virtual address space to userspace. Now if i run stressapptest in userspace with 80% of the available memory shown using cat /proc/meminfo , it throws an error saying "failed to allocate memory".

Is there any way to find how much excat amount of virtual address space is allocated for userspace?

root@:/#
root@:/# cat /proc/meminfo | head -5
MemTotal:        1826896 kB
MemFree:         1708308 kB
MemAvailable:    1694060 kB
Buffers:            2484 kB
Cached:             9520 kB
root@:/#
root@:/# ./stressapptest -M 900
2021/09/25-06:48:59(UTC) Log: Commandline - ./stressapptest -M 900
2021/09/25-06:48:59(UTC) Stats: SAT revision 1.0.7_autoconf, 32 bit binary
2021/09/25-06:48:59(UTC) Log: varada @ CHEPSSW01 on Wed Aug 27 12:05:13 IST 2014 from open source release
2021/09/25-06:48:59(UTC) Log: 1 nodes, 4 cpus.
2021/09/25-06:48:59(UTC) Log: Defaulting to 4 copy threads
2021/09/25-06:48:59(UTC) Log: Flooring memory allocation to multiple of 4: 900MB
2021/09/25-06:48:59(UTC) Log: Prefer plain malloc memory allocation.
2021/09/25-06:48:59(UTC) Process Error: memalign returned 0
2021/09/25-06:48:59(UTC) Process Error: failed to allocate memory
2021/09/25-06:48:59(UTC) Process Error: Sat::Initialize() failed
2021/09/25-06:48:59(UTC)
2021/09/25-06:48:59(UTC) Status: FAIL - test encountered procedural errors
2021/09/25-06:48:59(UTC)
2021/09/25-06:48:59(UTC) Process Error: Fatal issue encountered. See above logs for details.
root@OpenWrt:/#

Answer 1

Every single process has a different virtual address space, you don't have a global "userspace" virtual address space. What VMSPLIT_1G does is simply limit the range of virtual addresses available to userspace programs. You can very well have multiple programs where the entire 1G of available virtual address space is mapped, but still have memory available because the pages are not actually resident in main memory.

If you want to take a look at how much memory is currently in use, then /proc/meminfo is what you are looking for, but keep in mind that you have to check it when your program is running, not before/after running it, as that would be pointless. As per individual processes, you have /proc/[PID]/stat and /proc/[PID]/status which both provide the "resident set size" (amount of used virtual memory memory actually resident in main memory), or you can take a look at /proc/[PID]/maps to inspect the virtual addresses used by a specific process.

Now if i run stressapptest in userspace with 80% of the available memory shown using cat /proc/meminfo , it throws an error

This seems to be expected in your configuration, it may happen for different reasons, the most likely one is that the program is trying to request a single block of memory that is too large, and the memory allocator used by the program (ie Glibc's malloc ) cannot allocate one, so it returns failure even if technically there still is some free memory to use.

For example, even if you have a lot of free main memory, but your process has a virtual address which is almost full, and you try to do a single mmap with a size that is too large, the kernel will not be able to fit those many pages in a contiguous block of virtual memory and will return failure.