Skip to main content
22 events
when toggle format what by license comment
Mar 14, 2020 at 16:52 comment added John Terragon Nope. As I mentioned above the bug I filed got some attention and they recognized that kswapd was behaving badly without any reasonable memory pressure. But since then there was no activity whatsoever. And the bug is still there with the latest kernel. I just gave up and upgraded to a system with 64GB so f*$k it!
Jul 2, 2019 at 8:22 comment added ctrl-alt-delor Did you resolve this? Can you give an update?, ether way.
Apr 25, 2019 at 8:33 comment added U. Windl Noticing you fill your memory with zeros, I think recent Linux does handle pages of zeros specially. Did you try using different values, maybe random?
S Apr 5, 2019 at 20:33 history edited RalfFriedl CC BY-SA 4.0
fixed title
S Apr 5, 2019 at 20:33 history suggested Paradox CC BY-SA 4.0
fixed title
Apr 5, 2019 at 20:26 review Suggested edits
S Apr 5, 2019 at 20:33
Mar 6, 2019 at 15:30 answer added bodqhrohro timeline score: 1
Feb 15, 2019 at 19:24 comment added val - disappointed in SE I think I often met it in practice, so I had to disable swap completely and use zram (hadn't any trubles with it yet).
Oct 12, 2018 at 20:34 comment added filbranden Very interesting discussion on the kernel bug! And it looks like you isolated this problem to swap partition encrypted with LUKS. You might want to edit your answer or possibly post an answer yourself (with the workarounds known so far, and perhaps keep updating it as the LKML discussion gets to more conclusive results.) Really impressive to see the Linux kernel community at work! 😁
Jun 25, 2018 at 19:00 history edited John Terragon CC BY-SA 4.0
added 187 characters in body
May 23, 2018 at 13:43 answer added Jeremy Boden timeline score: -3
May 4, 2018 at 22:21 history tweeted twitter.com/StackUnix/status/992529654199222273
May 4, 2018 at 16:28 history edited John Terragon CC BY-SA 4.0
added 290 characters in body
May 4, 2018 at 14:59 comment added John Terragon swappiness is the default 60 (not that changing it gives a better result). The kernel used with the vmstat run is 4.14.35 but I've tried 4.15, 4.16 and I've even gone back to the 4.0 series (!): always the same behavior. And it's not that I'm using some weird distribution, it's just debian. I don't use the kernel images from debian (not that mine have unusual configs) but I've tried one of those...same behavior.
May 4, 2018 at 13:30 comment added sourcejedi Wow. Software behaviour varies between versions :-P, please post uname -r. I would also suggest showing the value of the configurable option, cat /proc/sys/vm/swappiness, not that it's likely to explain this but it might help think about different theories.
May 4, 2018 at 13:05 comment added John Terragon I used vmstat. Results in the update above.
May 4, 2018 at 12:35 history edited John Terragon CC BY-SA 4.0
added 2605 characters in body
May 4, 2018 at 11:22 comment added John Terragon If I start vmstat 1 with stdout output, I think it's going to freeze. But you're right, I could just start vmstat 1>somefile directly from the system and then see what it reports after the system has come back to life. I'll try that.
May 4, 2018 at 3:56 comment added Mark Plotnick Sorry, meant to say: can you ssh into your system from another system and start the command vmstat 1 just prior to running your big malloc program?
May 3, 2018 at 16:59 comment added John Terragon As I mentioned, everything is locked. I tried ssh'ing from another system it just times out.
May 3, 2018 at 16:54 comment added Mark Plotnick Can you ssh into your system from another system and run vmstat 1 while this is happening?
May 3, 2018 at 16:08 history asked John Terragon CC BY-SA 4.0