http://bugzilla.suse.com/show_bug.cgi?id=959822 Bug ID: 959822 Summary: Zypper causes frequent kernel "page allocation failure" when downloading packages, running in KVM. Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: hguo@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- The virtual machine is a fresh instance running the official Leap template on Google compute cloud (i.e. KVM). After having created and enabled a swap file of 1 GB, I attempted to install ~3500 software packages using zypper. Several minutes into the process, while zypper is still downloading packages, swap usage climbs slightly (by 6 MB), and frequent "page allocation failure" begins to occur. Attach log is the system journal and failure stack traces. Note that - under identical swap setup and zypper invocation, the virtual machine running official Leap template on AWS EC2 (i.e. Xen) does not rise swap usage, and the allocation failures never occur. This is the memory situation when failures begin to occur: \ total used free shared buffers cached Mem: 3548 1794 1753 287 53 1447 -/+ buffers/cache: 293 3254 Swap: 1023 6 1017 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 7 1822 56 1530 0 0 69 509 156 247 4 1 94 1 0 1 0 7 1822 56 1530 0 0 0 324 195 258 1 0 98 0 0 0 0 7 1822 56 1530 0 0 0 228 258 315 2 0 98 0 0 0 0 7 1823 56 1530 0 0 0 108 309 399 1 0 99 0 0 0 0 7 1824 56 1531 0 0 0 340 379 358 1 0 99 0 0 0 0 7 1825 56 1532 0 0 0 572 442 369 1 1 98 0 0 0 0 7 1826 56 1532 0 0 0 1156 332 353 1 0 99 0 0 0 0 7 1827 56 1534 0 0 0 0 549 492 0 1 100 0 0 0 0 7 1827 56 1535 0 0 0 0 492 509 0 0 99 0 0 0 0 7 1828 56 1537 0 0 0 0 495 467 1 0 99 0 0 Sysctl vm settings are following (image default - never changed manually): vm.admin_reserve_kbytes = 8192 vm.block_dump = 0 vm.compact_unevictable_allowed = 1 vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 vm.dirtytime_expire_seconds = 43200 vm.drop_caches = 0 vm.extfrag_threshold = 500 vm.hugepages_treat_as_movable = 0 vm.hugetlb_shm_group = 0 vm.laptop_mode = 0 vm.legacy_va_layout = 0 vm.lowmem_reserve_ratio = 256 256 32 vm.max_map_count = 65530 vm.memory_failure_early_kill = 0 vm.memory_failure_recovery = 1 vm.min_free_kbytes = 7512 vm.min_slab_ratio = 5 vm.min_unmapped_ratio = 1 vm.mmap_min_addr = 65536 vm.nr_hugepages = 0 vm.nr_hugepages_mempolicy = 0 vm.nr_overcommit_hugepages = 0 vm.nr_pdflush_threads = 0 vm.numa_zonelist_order = default vm.oom_dump_tasks = 1 vm.oom_kill_allocating_task = 0 vm.overcommit_kbytes = 0 vm.overcommit_memory = 0 vm.overcommit_ratio = 50 vm.page-cluster = 3 vm.panic_on_oom = 0 vm.percpu_pagelist_fraction = 0 vm.stat_interval = 1 vm.swappiness = 60 vm.user_reserve_kbytes = 109775 vm.vfs_cache_pressure = 100 vm.zone_reclaim_mode = 0 -- You are receiving this mail because: You are on the CC list for the bug.