> How easily can the OS take the memory back from Chrome to run something else (that one is easy, it can not, except on the last case scenario where it kills process).

It actually can. It's called swapping. An amazing technology from the 90s.

That's not what GP meant, the analogous situation is loading GBs of data into a database, resulting in a GBs sized file on disk. If you truncate the data, it's gone, but the database won't actually shrink the file on disk unless you vacuum too. Chrome might not be using all the memory it has claimed, but it's not necessarily releasing all that it can back to the system either.

> but it's not necessarily releasing all that it can back to the system either.

That's exactly the point of swapping. Memory which was not used in a (relatively) long time is taken away forcefully from the process if there is memory pressure on the system.

So it doesn't matter if Chrome releases it or not, it will be taken away if it just sits there.

> is taken away forcefully

To disk. Waiting for the memory a badly behaved app overzealously ate up without using to finish flushing to disk before being able to use it is worse than simply having the memory readily available. This is why I always disable swap, opting to let bad processes die, sometimes even pulling the trigger myself.

If you ever hit actual swapping, then your system performance is already way past the point of no return.

In modern systems, paging is okay. But not swapping.

In even more modern systems, with NVMe NAND storage, even swapping is ok.

> from the 90s.

From the 60s. Atlas computer had virtual memory. I originally thought it was the System360.

https://www.computerhistory.org/timeline/1962/

That's what the virtual memory system does, provided you're not running with swap disabled. A page fault isn't hard for the kernel to handle, it's just a severe performance hit.