On Thursday, August 16, 2018 at 10:06:54 PM UTC+2, Brendan Hoar wrote: > On Thursday, August 16, 2018 at 3:21:27 PM UTC-4, Marcus Linsner wrote: > > The good news is that I've realized that the OOM triggering was legit: I > > had firefox set to use 12 cores at once and 14GiB of RAM was clearly not > > enough! (8 and no ccache was good though - did compile it twice like so) > > > > The bad news is that I still don't know why the disk-read thrashing was > > happening for me, but I will default to blame the OOM (even though no swap > > was active, ie. I swapoff-ed the swap partition earlier) due to previous > > experience with OOM triggering on bare-metal hardware: I seem to remember > > SSD disk activity led being full-on during an impending OOM and everything > > freezing! > > Maybe this applies: > > https://askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap > > [[if kswapd0 is taking any CPU and you do not have swap, the system is nearly > out of RAM and is trying to deal with the situation by (in practise) swapping > pages from executables. The correct fix is to reduce workload, add swap or > (preferably) install more RAM. Adding swap will improve performance because > kernel will have more options about what to swap to disk. Without swap the > kernel is practically forced to swap application code.]] > > This could be a reason you only see reads hammering the drive, maybe? > > Also worth remembering: every read is decrypting block(s) which takes some > CPU (even on systems with AES-NI support). > > Brendan
Thank you Brendan! The following comment(from the webpage that you linked) explained the constant disk-reading best for me: "For example, consider a case where you have zero swap and system is nearly running out of RAM. The kernel will take memory from e.g. Firefox (it can do this because Firefox is running executable code that has been loaded from disk - the code can be loaded from disk again if needed). If Firefox then needs to access that RAM again N seconds later, the CPU generates "hard fault" which forces Linux to free some RAM (e.g. take some RAM from another process), load the missing data from disk and then allow Firefox to continue as usual. This is pretty similar to normal swapping and kswapd0 does it. " - Mikko Rantalainen Feb 15 at 13:08 $ sysctl vm.swappiness vm.swappiness = 60 In retrospect, I apologize for hijacking this thread, because it now appears to me that my issue is totally different from the OP(even though the subject still applies): On Friday, August 10, 2018 at 9:02:31 PM UTC+2, Kelly Dean wrote: > Has anybody else used both Qubes 3.2 and 4.0 on a system with a HD, not SSD? > Have you noticed the disk thrashing to be far worse under 4.0? I suspect it > might have something to do with the new use of LVM combining snapshots with > thin provisioning. > > The problem seems to be triggered by individual qubes doing ordinary bursts > of disk access, such as loading a program or accessing swap, which would > normally take just a few seconds on Qubes 3.2, but dom0 then massively > multiplies that I/O on Qubes 4.0, leading to disk thrashing that drags on for > minutes at a time, and in some cases, more than an hour. > > iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and [21.xvda-1], > reading the disk at rates ranging from 10 to 50 MBps (max throughput of the > disk is about 100). At this rate, for how prolonged the thrashing is, it > could have read and re-read the entire virtual disk multiple times over, so > there's something extremely inefficient going on. > > Is there any solution other than installing a SSD? I'd prefer not to have to > add hardware to solve a software performance regression. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c184a781-3883-443a-b719-6b6817a4de7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
