What is the minimum of memory required for the ARM Linux Burnin program to run?

[karry]

After running the Passmark test on two network interfaces and two disks for a period of time, the program would automatically exit and an error message like the one shown in the figure would appear regarding Ethernet. For instance, I set the program to run for 12 hours, but actually it automatically stopped the test within less than an hour.
My product has only 2GB of memory. After the system boots up, the remaining memory is approximately 1.4GB.

[karry]

For the detailed test log, please refer to the attachment. This is the result of the last test.

[David (PassMark)]

The error, ethernet failed to alloc skb entry, occurs when the system is low on RAM.
SKB is the socket buffer, they are central data structure representing a network packet, acting as a container that holds the actual packet data (payload and headers).
So no buffers available means no network.

So then the question is why is there no free memory. Is it becuase
A) There is no swap file setup, but should be.
B) You are just running too much on this machine (compared to the very limited hardware capabilities)
C) There is a resource leak. So over time free RAM decreases when under load. Eventually leading to a guaranteed crash.

2GB with a light version of Linux should be enough to run BurnInTest.

[karry]

I have observed that when both the disk and network are being tested simultaneously, the memory will soon be exhausted.

However, if the disk test is cancelled and only the Network test is conducted, there will be no abnormalities during the two-hour test.（The remaining memory has consistently remained at around 900MB.）
root@linaro-alip:~# free -h
total used free shared buff/cache available
Mem: 1.9Gi 341Mi 986Mi 15Mi 641Mi 1.6Gi
Swap: 0B 0B 0B

[David (PassMark)]

Any good reason for having 0B swap file? (like having a SDCard with very limited write cycles)

My guess at what is happening here is:
1) Linux uses free RAM for disk caching (this is normal).
2) Linux should release the cache when required for new apps to run
3) The network driver isn't a normal app however. It runs in the Kernel in an interrupt handler. So can't wait around for free RAM to become available.
4) The network driver tries to allocate some RAM, but fails, can't release the cache and can't use swap. So it dies.

This all probably means your system is short of physically installed RAM but also badly configured.

Try to increase vm.min_free_kbytes to a larger value. Maybe 64MB instead of what might be the default of ~10MB.

sysctl -w vm.min_free_kbytes=65536

This forces the kernel to start reclaiming cache earlier, ensuring the "Free" column never drops dangerously low. To make the change permanent you can add it to the /etc/sysctl.conf file.

[karry]

I allocated sufficient memory to the LAN Port through the following command. After testing for two hours, there were no issues. Is this approach a suitable final solution?

echo 200000 > /proc/sys/net/core/netdev_max_backlog
echo 262144 > /proc/sys/net/core/optmem_max
ethtool -G eth0 rx 4096 tx 4096
ifconfig eth0 txqueuelen 10000
ethtool -G eth1 rx 4096 tx 4096
ifconfig eth1 txqueuelen 10000
echo 1 > /proc/sys/vm/compact_memory
echo 32768 > /proc/sys/vm/min_free_kbytes

[David (PassMark)]

Is this approach a suitable final solution?

That is more of a business decision. Other device drivers might have the same problem. We don't know what the exact risk is and we don't know what type of solution you are shipping.

[karry]

Could the setting be like this to ensure that Passmark Burnin runs successfully for 12 hours without automatically quitting midway due to insufficient RAM capacity?

[David (PassMark)]

You would need to do some testing for 12 hours to confirm it allows for a run of 12 hours. We can't predict this with any certainly with the information we have.

[karry]

Could you please confirm again what is the minimum required memory capacity for the PassMark Burnin Linux_ARM V5 program? Below what capacity should this program not be used?

[David (PassMark)]

Installed memory capacity doesn't mean much if Linux (or 3rd party software) uses it all.

For Linux itself around 128MB is required for tiny embedded systems (e.g. Alpine Linux) to 4GB for modern desktops (Ubuntu) and 8GB+ for comfortable general use

BurnInTest has a command line version and a GUI version. Around 10MB should be enough for the GUI version and 5MB for the command line to launch it. But the requirement will change a lot depending on what tests are run in BurnInTest. For example the RAM test will use nearly all available RAM.

[karry]

Installed memory capacity doesn't mean much if Linux (or 3rd party software) uses it all.

For Linux itself around 128MB is required for tiny embedded systems (e.g. Alpine Linux) to 4GB for modern desktops (Ubuntu) and 8GB+ for comfortable general use

BurnInTest has a command line version and a GUI version. Around 10MB should be enough for the GUI version and 5MB for the command line to launch it. But the requirement will change a lot depending on what tests are run in BurnInTest. For example the RAM test will use nearly all available RAM.

I understand that "5MB is only enough to start the command line burnin", but even if RAM testing is not conducted, the testing items still consume memory. For example, testing USB, Disk or Network.
For instance, if I need to test two 1Gbps connections or two disks, then what is the minimum amount of available RAM that my system needs to have?

Because this minimum configuration is crucial for us to assess whether we can continue to use the PassMark Burnin Linux ARM software.

[David (PassMark)]

The default buffer size for disk reads and writes is 4MB. This is per disk, but the buffer is reused. So maybe add 20MB to the base requirements to be safe for your setup.
I don't remember the network buffer size, but adding 10MB should be safe. So maybe 40MB in total. But you can easily measure the exact amount for your setup using Linux tools like "Top".

Using the disk and network will also result in the operating system creating caches and buffers (this isn't in our control). There might also be 3rd party software using more RAM. For example if you have a security anti-virus solution or firewall running, using the disk and network might also trigger those packages to be more active use slightly more RAM.