Bjoern Voigt wrote:
I wonder why "swapoff -a" takes so long (7:44 minutes). There is enough free RAM space (after resuming from hibernate). I currently have two swap partitions, one on a WD red hard disk and one on a SSD. But even before (only SSD swap space) the swapoff time was nearly the same.
mybox:~ # iotop mybox:~ # free total used free shared buff/cache available. Mem: 8104720 3435540 3510580 15192 1158600 4492152 Swap: 38281208 3277124 35004084 mybox:~ # time swapoff -a
real 7m44.407s user 0m0.000s sys 4m37.312s mybox:~ #
# grep swap /etc/fstab UUID=7c287338-bb71-41e1-a5cf-789f6fea25d3 swap swap pri=1 0 0 UUID=93313bb7-d7cd-4978-9882-079d4a803b72 swap swap pri=2 0 0
My setup: - CPU: Intel Core i5 CPU 750 @ 2.8GHz - openSUSE Tumbleweed x86_64 - 8 GB RAM - SWAP: 20 GB on SSD, 16 GB on WD red hard disk, no SWAP encryption
I doubt, that the long swapoff time is not only a theoretical problem. I have several phenomenons which can be related:
* System feels sluggish after resuming from hibernate. This problem became stronger after removing 8 GB RAM from 16 GB before. With "iotop" I found, that there is much I/O SWAPIN traffic. * Shutdown can take some minutes * Even with much less used SWAP memory swapoff takes too long
Any ideas? What is a reasonable time for swapoff? I probably found the answer. It's a Kernel problem:
"The function responsible for deactivating an area is, predictably enough, called sys_swapoff(). This function is mainly concerned with updating the swap_info_struct. The major task of paging in each paged-out page is the responsibility of try_to_unuse() which is /extremely/ expensive. For each slot used in the swap_map, the page tables for processes have to be traversed searching for it. In the worst case, all page tables belonging to all mm_structs may have to be traversed. Therefore, the tasks taken for deactivating an area are broadly speaking;" Sources: https://www.kernel.org/doc/gorman/html/understand/understand014.html#toc81 http://www.faqoverflow.com/unix/45673.html Unfortunately nobody seems to work on this. There was a discussion 2007 on Kernel mailing list, but without results: http://copilotco.com/mail-archives/linux-kernel.2007/msg39423.html Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org