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 пишет:
If you are short of memory but there is swap available, swap will be used instead.
That is wrong.
It's not that he's "wrong" per se but that he'd worded it badly. You go on to more accurately describe what is happening.
sure, but do the kernel care that it's swap, not physical memory?
in an other way, is 5 Gb of physical memory and 5 Gb of swap identical of 10Gb of physical memory?
No. If there is no free memory to satisfy allocation request, kernel will look for cold data in memory and will try to reclaim it.
All memory is either statically allocated for the kernel and/or it's threads or is available to the VM system. The latter is ALL on one of a number of linked lists.
Not all memory has a corresponding swap location, so there is no need for the size(swap) = size(RAM) Why is this? You never need to swap out code! Late model VM has memory mapped files. This is wonderful for the VM's "load on demand" capability if the CPU can do instruction restart. Most can these days but it was a problem with some of the original set of 16-bit CPUs and unavailable with the 8-it. SUN pulled a trick with a pair of 68000 chips, one a step behind the other, the fudge the restart capability on a chip that didn't have it. Fantastic engineering kludge!
You never need to swap out code, you just have to mark that page as one that can be put on the 'dirty' queue and as it fails to be accessed it 'ages' along to the end, where it can, if necessary, be reclaimed. How fast that happens, how aggressively the pages are plucked from that queue for re-use are tunable parameters. Note I said "as it fails to be accessed". If it is accessed, that pages code gets accessed -- i.e. executed -- then it is brought back to the tail of the queue.
Suppose that code page ages out and gets re-used 'cos the application isn't needing it ... for a while, but then the application gets round and needs that code fragment again. The page isn't there, there is a page-fault triggered, execution is suspended and the page needs to be brought back in. It is a page of a memory mapped file, so it is NOT in swap. It never was; it never will be.
Swap is used to preserve content of anonymous memory that is reclaimed.
I don't know that I'd call it 'anonymous'. This is the volatile memory that belongs to processes.
"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? 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) Only DEC made it just as cpu-expensive afaicr. It's only those extreme mem-hogs like "some webbrowsers" and ill-programmed database queries that caused systems to go thrashing. But after all, needing 512GB mem or more? I really wonder why... I once had two 64-core machines with 2TB mem, but that was for running hundreds of virtual desktops. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org