On 18/01/2020 18:49, Carlos E. R. wrote:
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.
In late model Linux, that is, post about 2.6, all file IO is mmap9)ed, either explicitly or by the kernel. So the executable binaries, either the stuff in /usr/bin or the DOT-SO files in /usr/lib (or wherever) are opened as files and mmap()d. That is as long as they are in use, that is, the program is not terminated and there is some process using the shared or dedicated libraries. As files, they have file descriptors. That is the important part. Perhaps that is what makes this different from Windows. The inodes are cached, of course, so the pointers to the disk, if and when the pages of code are to be read in, are there already. But once read in ... At worst, they become unused and are marked 'dirty'. and the dirty queue is merely some pages that MIGHT be recoiled. It doesn't mean they have been released, yet. I don't know what you mean by 'jump table' and don't know what you mean by it being recalculated every time ... Yes, the prime binary has the list of the libraries it makes use of. You can see that with the 'ldd' command:
ldd /bin/bash linux-vdso.so.1 (0x00007ffc7d95f000) libreadline.so.7 => /lib64/libreadline.so.7 (0x00007fbc6c498000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbc6c294000) libc.so.6 => /lib64/libc.so.6 (0x00007fbc6beda000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fbc6bcac000) /lib64/ld-linux-x86-64.so.2 (0x00007fbc6c9ec000)
I don't know if you are talking about the VM mapping when you talk of jump tables. I donb't see what 'every time' has to do with it. Once set up in the processes virtual memory, it is simply that the page tables are there. They constitute a complete entity. If the page is there then it's just like it is there, no recalculation. As far as I know, the OS sets that up for the hardware to do autonomously. If it isn't there then a page fault is raised. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org