-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2020-01-18 a las 22:14 +0100, suse@a-domani.nl escribió:
On 2020-01-12 17:15, Anton Aylward wrote:
On 12/01/2020 04:15, Andrei Borzenkov wrote:
12.01.2020 11:57, jdd@dodin.org пишет:
...
"Volatile memory"? Consider: at startup a processes reads one or more config files. It opens them in read-only mode. The VM opens them as memory mapped files; the process digested them then closes them. They may be in the data space, but they are not volatile, they are read-only. When closed, their mapping tables entries and their mapped virtual memory are freed. But while they are, strictly speaking, in the data space of the application, they are like code pages. if the demand of multi-tasking necessitates suspending that process it may be that those pages get released so something else can run. (I agree, context and circumstances make it unlikely that a startup config read gets this treatment. But the logic does apply.) Like the code pages mentioned above the contents of the read-only file can be re-mapped 'on demand'. They don't need to go to swap.
Nice discussion, revives old (swapped-out) memories. Doesn't the kernel tries to make use of ALL available memory?
Yes.
Files that are written back to disc, but still kept in mem (just in case)... And all the code-pages, that are once loaded into mem, but never used, is there any need for them to stay in mem? (writing a number of mem-segments to swap might be faster, than re-loading binary pages from the executable)
Maybe. Windows did this trick of reloading code from the exe files. I saw it in the documentation of 3.10. It conserves disk space, and writing time, but it is slower reading because the object has to be found in disk, and because exes have a jump table that has to be recalculated; ie, every jump in the code on file has to be recalculated to match the position in ram. Frankly, I don't know myself if Linux does this or not. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXiOZdxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVBIoAn3roAOJnFvVnJju428up N3qmLmHUAKCNC9JYFKaBFedcUQ+nj3ve7pqQ8g== =WOxJ -----END PGP SIGNATURE-----