On an unrelated note(but since btrfs was thought to be a problem at some
point), I've discovered that btrfs with zstd:5 (or worse zstd:15) can
cause (at least) mouse cursor stuttering(like it was skipping frames),
while zstd:1 doesn't(likely because of the low CPU usage during
compression), regardless of how fast/many writes are happening on the
SSD(2-6M/s with zstd:15, 38-50+M/s with zstd:1), apparently due to high
CPU usage during the compression. (zstd unspecified means zstd:3 aka
default)

Normal CPU usage by itself(eg. during compiling) doesn't cause such
stuttering though. I've tested this on a Lenovo Ideapad Z575, 16G RAM,
Kingston SSD SA400S37240G firmware SBFK71F1, and I've personally
switched to zstd:1

ie.
```
diff --git a/fs/btrfs/zstd.c b/fs/btrfs/zstd.c
index 6b9e29d050f3..02ffdb27c360 100644
--- a/fs/btrfs/zstd.c
+++ b/fs/btrfs/zstd.c
@@ -22,7 +22,7 @@
 
 #define ZSTD_BTRFS_MAX_WINDOWLOG 17
 #define ZSTD_BTRFS_MAX_INPUT (1 << ZSTD_BTRFS_MAX_WINDOWLOG)
-#define ZSTD_BTRFS_DEFAULT_LEVEL 3
+#define ZSTD_BTRFS_DEFAULT_LEVEL 1
 #define ZSTD_BTRFS_MAX_LEVEL 15
 /* 307s to avoid pathologically clashing with transaction commit */
 #define ZSTD_BTRFS_RECLAIM_JIFFIES (307 * HZ)
```

but zstd:1 in /etc/fstab should also work, unless using too old kernel
that doesn't know about it (hence why I prefer using the patch anyway)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1833281

Title:
  System freeze when memory is put on SWAP in Linux >4.10.x

Status in Linux:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I'm reporting this since it's reproduceable the 70% of the time.
  Summary:

  In different circumstances, when the systems starts to swap out RAM
  memory, even small amounts, the system becomes completely unusuable
  and the screen freezes up, no mouse movement, no TTY access or SSH
  access can be made, only SYSRQ keys seem to do something (only reboot,
  so REISUB worked so far though, OOM is useless since the memory/swap
  is not even full)

  The I/O Disk led is stuck to 100% in ALL the following cases when this
  happens.

  So far:
  - This happens even when only ZRAM is enabled, and no swap partition is used.
  - Happens when ZSWAP is used with a swap partition
  - Happens also when a partition without zram or zswap is used
  - Maybe it's AMD specific? 

  However, I'm not experiencing this on my laptop using the same tests.

  My laptop is an Intel one, while my desktop is an AMD Ryzen platform.

  Here are the specs:
  CPU: AMD Ryzen 5 1600 no OC
  GPU: AMD RX 580 8GB
  SSD: Crucial MX500 500GB
  MOBO: MSI B350M Grenade
  RAM: 8GB HyperX Kingston 2667Mhz

  Ubuntu version: 18.04 LTS, backports repo enabled
  Kernel version: 4.18.0-18, official ubuntu repo
  Bios settings: Default

  Additional info: Maybe I'm not 100% sure, but I noticed when using the
  5.0.0-17 generic kernel, the lockups seem to still happen, but they
  recover eventually. Happened only a few times though...

  But will always be frozen for at least 30 seconds, differently from my
  intel laptop where those do occur.

  The SSD make is the same. I bought two of these, they got also the
  same amount of RAM.

  In my laptop those do not occur at all. Swapping memory even huge
  quantities like 1GB or more, do not produce any issues.

  Tests made:
  For testing this behaviour I tried:

  - Compiling the chromium-browser source code (takes up a lot of system
  RAM)

  - Used the "stress" command, using a specific amount of memory to
  decide how many it will be swapped, and here I noticed that even small
  quantities like a couple of megabytes will cause the system to freeze
  the 70% of the times

  Example: "stress --vm 1 --vm-bytes=7G"

  What should happen:
  I expect system slowdowns when swapping out memory since I do not have enough 
RAM, but unlikely when using Windows or my laptop with the same Linux version, 
not a completely unusuable environment. The swap partition is in both cases on 
an SSD.

  Reproduceability: 70% of the times

  Additional info again:
  I'm not sure this is due to any hardware failure, my SSD health is fine, as 
my CPU and RAM. As I said swapping in Windows works fine...
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  AudioDevicesInUse:
   USER        PID ACCESS COMMAND
   /dev/snd/controlC1:  haru       2076 F.... pulseaudio
   /dev/snd/controlC2:  haru       2076 F.... pulseaudio
   /dev/snd/controlC0:  haru       2076 F.... pulseaudio
  CurrentDesktop: communitheme:ubuntu:GNOME
  DistroRelease: Ubuntu 18.04
  IwConfig:
   enp24s0   no wireless extensions.
   
   lo        no wireless extensions.
  MachineType: Micro-Star International Co., Ltd. MS-7A37
  Package: linux (not installed)
  ProcFB: 0 amdgpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.0.0-17-generic 
root=UUID=75d45574-7169-4653-aea3-9f95087f0806 ro rootflags=subvol=@ quiet 
splash vt.handoff=1
  ProcVersionSignature: Ubuntu 5.0.0-17.18~18.04.1-generic 5.0.8
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-17-generic N/A
   linux-backports-modules-5.0.0-17-generic  N/A
   linux-firmware                            1.173.6
  RfKill:
   0: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
  Tags:  bionic
  Uname: Linux 5.0.0-17-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: sudo video
  WifiSyslog:
   
  _MarkForUpload: True
  dmi.bios.date: 01/22/2019
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.K0
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: B350M MORTAR (MS-7A37)
  dmi.board.vendor: Micro-Star International Co., Ltd.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: To be filled by O.E.M.
  dmi.chassis.type: 4
  dmi.chassis.vendor: Micro-Star International Co., Ltd.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.K0:bd01/22/2019:svnMicro-StarInternationalCo.,Ltd.:pnMS-7A37:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnB350MMORTAR(MS-7A37):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct4:cvr1.0:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: MS-7A37
  dmi.product.sku: To be filled by O.E.M.
  dmi.product.version: 1.0
  dmi.sys.vendor: Micro-Star International Co., Ltd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1833281/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to