Document scenarios where the buff/cache will NOT be reclaimed about linuxatemyram.com HOT 3 OPEN

One case where disabling the disk cache would be very useful is WSL2. My Windows memory currently is sitting at 97% w/ WSL2 using 17,493 MB, out of ~32GB.

I'm also annoyed that linuxatemyram.com says there are no cases and avoids answering the question. I don't have a problem with "most people shouldn't try to fiddle with this", but in this case AFAIK disabling it would solve my issue. So the site is wrong.

If anyone comes here looking for a way to clear some RAM quickly, a workaround is: echo 1 | sudo tee /proc/sys/vm/drop_caches. Source and more info

For the curious I posted my usage numbers to: microsoft/WSL#4166

from linuxatemyram.com.

I've created a PR with said workaround: #23

from linuxatemyram.com.

It's a quite old comment but IMO there is an important point that should be noted. So let's start:

I'm also annoyed that linuxatemyram.com says there are no cases and avoids answering the question. I don't have a problem with "most people shouldn't try to fiddle with this", but in this case AFAIK disabling it would solve my issue. So the site is wrong.

The problem with WSL2 is mentioned in their documentation:

You have strict memory requirements
WSL 2's memory usage grows and shrinks as you use it. When a process frees memory this is automatically returned to Windows.
However, as of right now WSL 2 does not yet release cached pages in memory back to Windows until the WSL instance is shut down.
If you have long running WSL sessions, or access a very large amount of files, this cache can take up memory on Windows.
We are tracking the work to improve this experience on the WSL Github repository issue 4166

Also they (Microsoft staff) mention (in the 4166 issue) a pretty aggressive default setting for WSL2 memory up to 80% of host's RAM. Later it is corrected to 50% or 8GB.

This is my attempt to explain the observed behaviour and the underlying problem:

1. There is an important missing detail: https://linuxatemyram.com talks about the case when we are using the Linux kernel as a host kernel i.e. it is responsible for managing the interactions of the applications with the available hardware including the RAM memory. Using the Microsoft WSL2 is not the same case - WSL2 is using a HyperV virtual machine (VM) to run the Linux kernel but the Windows kernel is the host OS kernel. - So when a given kernel is operating as host kernel it doesn't bother with the possibility that something else may need the memory resources. The kernel assumes that the accessible memory is all for its own use. The situation is very different when there are a host kernel and a guest kernel: 1) There is no way for the host kernel to ask the guest kernel: "Give me back some of the memory I've assigned to you". 2) Also there is no way to take it back without breaking the guest memory because the host doesn't know what is and where it is stored in the guest memory. 3) the guest kernel is not able to say to the host: "Here is some memory range that I no longer need". Conclusion: once the memory is given to the VM/guest kernel there is no way for the host kernel to reclaimed it. This is one of the reasons of containers popularity. The containers are basically native OS processes (with some fancy additional safety net around them) so the host OS can reallocate the freed memory for some other purpose (give it to other process/container or use it as a file system cache). So it is possible to achieve higher density (more isolated computing systems) per one real host. Also if some guest needs temporary more memory it's very easy to achieve.
2. The old WSL1 was using a different approach - provide an emulation layer to translate the Linux kernel system calls to their equivalents in the Windows kernel. - in this scenario there is no dedicated memory for a second (guest) kernel so there isn't a possibility to observe the mentioned behaviour. All the RAM is managed by only one kernel.

More resources about the subject (maybe the other could add more related information about the other hypervisors):

• For example Oracle VirtualBox has the feature of memory ballooning - it can move the free memory from one VM to another. But again it can't reclaim the memory from a guest and return it to the host kernel to be marked as free. The details are here: https://www.virtualbox.org/manual/ch04.html#guestadd-balloon

Conclusion:
adding a clarification about the difference between usage scenario only host kernel and any other usage scenario should prevent similar confusions.

from linuxatemyram.com.