Created attachment 109901 [details] reproducer I've observed this for a few years now, but I just recently set aside time to narrow down the specific conditions where the problem is relevant. Currently populating sections of memory that are larger than the system ram size on systems that are using encrypted swap will cause other processes to be non-interactive and uninterruptible for an often large time. Particularly, X on x86_64 seems unable to recover when another process does this kind of large memory population, whereas on i386 it only gets temporarily hung. When X isn't running, other processes like top or login are also affected with the same symptoms. This is only an issue when swap is encrypted. Plain swap is unaffected. Attached allocate.c is a reproducer for the issue and below is a session on x86_64 in an X session demonstrating success with plain swap and an unrecoverable hang with encrypted swap: $ gcc allocate.c -o allocate $ free -m total used free shared buffers cached Mem: 3412 520 2892 0 24 231 -/+ buffers/cache: 264 3147 Swap: 0 0 0 $ sudo swapon /dev/sda5 # plain swap area $ ./allocate 1024 MiB allocated + populated 2048 MiB allocated + populated 3072 MiB allocated + populated 4096 MiB allocated + populated 5120 MiB allocated + populated 6144 MiB allocated + populated 7168 MiB allocation failed 8192 MiB allocation failed ^C $ sudo swapoff /dev/sda5 $ sudo swapon /dev/mapper/sda4_crypt # encrypted swap area $ ./allocate 1024 MiB allocated + populated 2048 MiB allocated + populated 3072 MiB allocated + populated 4096 MiB allocated <system hang> There is also an ubuntu bug report about this problem, first noticed in 2007: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356 After some searching, as best I can tell this was not forwarded to kernel.org, so hopefully I am not duplicating existing knowledge.
I've seen the same behaviour here with several tools which scan and validate a very large bitmap etchmask for correctness.
I have recently started seeing freezes on my system that were hard to track down. They always happened while compiling huge packages -- and thus the system became under memory pressure (8 GiB no longer are what they used to be ;P). It took me a while to track this down but every time the system hits the encrypted swap partition, the system either freezes for a _very_ long time or freezes hard (usually the latter). If X is running, there is no escaping -- not even with magic sysrq keys. Everything hangs, even the keyboard. If in a terminal, you can switch between terminals and issue magic sysrq keys but those only print out an echo of the command itself or a help but the command itself is never executed -- except for the boot command. I tested several things: 1. different ciphers and block modes (aes, serpent, twofish, ...) 2. moved the swap from a RAID5 to dedicated partitions 3. experimented with several vm knobs (including but not limited to vm.min_free_kbytes and vm.swappiness) 4. w/ and w/o zswap Nothing made a difference at all. The systems works totally fine if the swap is not encrypted. This is easily reproducible at least on 4.4.x and 4.5.x (x64_64). Right now I am running w/o swap. If there is anything I can do to help track this down, please don't hesitate to let me know.
Forgot to add: I also tried w/ a swap file, which made no difference as well. Worth mentioning: I have been using an encrypted swap for ages, the freezes started only "recently" -- unfortunately I cannot put a finger on when exactly that was, which is why I can only say for sure that 4.4.x and 4.5.x are affected thus far.
I did some further diagnosing as well as a git bisect and posted all my findings to the linux kernel mailing list, as I figured it would get more attention there: http://marc.info/?l=linux-kernel&m=146099448410071&w=2 Like I said earlier, if there is anything else I can do, please let me know.