On 09/01/2020 10:08, Werner Flamme wrote:
a host should not start swapping, since it becomes slow when it does.
That is the ultimate issue. As I see it, there were two and ONLY two reasons why swap might happen. And on a VM system, 'swap' means paging to backing store. 1. Actual physical memory exhaustion. in the days when VM was a solution to memory being short because memory was expensive, the ditty was "virtual memory means virtual performance". Not enough physical memory meant the VM system was constnatantly working: page in, page out. Round and round it went. That was then, this is now. Memory is cheap; backing store is fast. (My limit is the Mobo won't take any more memory!) 2. The virtual memory system is badly configured. That means it is doing paging/swapping when it doesn't need to, when there is adequate memory for the demands bing placed upon it. There are a LOT of things you can adjust about the VM system, the page queue, how they age and circulate, but somewhere along the line pages might need to be written to backing store. How aggressively the ageing happens, how readily to swap processes happens is key here. At one level, this is going to be determined by the process churn. There is some interaction with the IO churn as IO buffers will need to be created, but they are queued separately, cached, and there should not be a great deal of 'crossover'. Of course this gets heartily confused with Linux for various reasons. One is 'binary reuse'. UNIX has always had the ability to share binaries, users using the same programs with different data space. With late model UNIX and with Linux this extends to the shared libraries. What makes this more complex is that those pieces of code are actually mapped memory to the disk locations. Every time a location on a 'page' is accessed for execution that page is pulled back in the ageing queue. Similarly with data. It is the unused stuff that gets aged and becomes candidates for page-out. Sometimes the page-out happens because pages are needed for input. That might be code or newly created data. Or data retrieved from swap. Which gets back to old model of inadequate memory and thrashing. Thus 'badly configured' is a very variable concept. While 'one size fits all' is never going to be absolutely true, there's a lot of 'one setting will suffice', be tolerable, for many situations. BUT realistically, the working profile and the specific demands needs to be examined and possibly some experimentation needs to be done. There's a lot you CAN tune! #ls /proc/sys/vm admin_reserve_kbytes lowmem_reserve_ratio oom_kill_allocating_task block_dump max_map_count overcommit_kbytes compact_memory memory_failure_early_kill overcommit_memory compact_unevictable_allowed memory_failure_recovery overcommit_ratio dirty_background_bytes min_free_kbytes page-cluster dirty_background_ratio min_slab_ratio panic_on_oom dirty_bytes min_unmapped_ratio percpu_pagelist_fraction dirty_expire_centisecs mmap_min_addr stat_interval dirty_ratio mmap_rnd_bits stat_refresh dirtytime_expire_seconds mmap_rnd_compat_bits swappiness dirty_writeback_centisecs nr_hugepages unprivileged_userfaultfd drop_caches nr_hugepages_mempolicy user_reserve_kbytes extfrag_threshold nr_overcommit_hugepages vfs_cache_pressure hugetlb_shm_group numa_stat watermark_boost_factor laptop_mode numa_zonelist_order watermark_scale_factor legacy_va_layout oom_dump_tasks zone_reclaim_mode Some guidelines for the informed at https://www.kernel.org/doc/Documentation/sysctl/vm.txt -- 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