Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDom0 freeze when almost out of memory #3969
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
schnurentwickler
Jun 7, 2018
Are you using a ssd and/or swap functionality?
Is your swappiness disabled and/or very low?
If I am using an hdd and my memory is full on another system, it swaps some memory data and my system stucks and is nearly unusable for a few minutes. It only happens on excessive memory usage.
schnurentwickler
commented
Jun 7, 2018
|
Are you using a ssd and/or swap functionality? If I am using an hdd and my memory is full on another system, it swaps some memory data and my system stucks and is nearly unusable for a few minutes. It only happens on excessive memory usage. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Polygonbugs
Jun 7, 2018
I'm using SSD(Samsung 850 Evo) with trim feature enabled and I'm also using swap in dom0. 8GiB of Swap is assigned for dom0(default install configuration) and it is not used much ususally. BTW, it seems make sense, swap could be problem. Then it could be not just specific kernel problem and could impact Qubes-4.0. Wondering, do you use 4.0 or 3.2?
Polygonbugs
commented
Jun 7, 2018
|
I'm using SSD(Samsung 850 Evo) with trim feature enabled and I'm also using swap in dom0. 8GiB of Swap is assigned for dom0(default install configuration) and it is not used much ususally. BTW, it seems make sense, swap could be problem. Then it could be not just specific kernel problem and could impact Qubes-4.0. Wondering, do you use 4.0 or 3.2? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
schnurentwickler
Jun 7, 2018
I am using the newest version.
For an ssd you could/should set swappiness to 1 or 2, instead the standard of 60. (probably percent)
Here are some shared informations about using a ssd on fedora or linux at all. (most distributions does have the same informations)
https://forums.fedoraforum.org/showthread.php?312512-SSD-configuration-with-Fedora-24-onwards
Also you should not set discard in your fstab or elsewhere as default.
Periodically fstrim is much more convenient for linux on ssd's. But read the forum post.
p.s.: I/O scheduler is not that important anymore. cfq made some approaches at ssd's.
schnurentwickler
commented
Jun 7, 2018
•
|
I am using the newest version. p.s.: I/O scheduler is not that important anymore. cfq made some approaches at ssd's. |
andrewdavidwong
added
bug
C: other
labels
Jun 8, 2018
andrewdavidwong
added this to the Release 3.2 updates milestone
Jun 8, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Polygonbugs
commented
Jun 8, 2018
|
Okay I'll try that and see if it happens again. |
Polygonbugs commentedJun 7, 2018
•
edited
Edited 1 time
-
Polygonbugs
edited Jun 7, 2018 (most recent)
-
Polygonbugs
created Jun 7, 2018
Qubes OS version:
Qubes-OS 3.2
Kernel : 4.14.18-1.pvops.qubes.x86_64
OS : Fedora-23
Affected component(s):
All VMs (Dom0 and DomUs)
Steps to reproduce the behavior:
Expected behavior:
Failed to opening new VM due to out of system memory. And give notification that the VM was not opened due to out of memory.
Actual behavior:
Every tasks, including all dom0 and domUs tasks, suddenly and temporary paused. Screen is freezed and all commands issued by user when this is happening are ceased until issue happening. Of course, mouse and keyboard are freezed. Problem could be continued for 1~5 minutes and then solved if nothing was happened. After everything comes back normally, a new VM could be opened successfully or failed to be opened by showing notification that the VM was not opened becaues of out of system memory.
General notes:
There is no journalctl log captured while this is happening. So I didn't post it. If you still need it, then I'll post it.
Related issues:
Could be related to OOM-killer on recent kernel (#3079). The only difference I think is OOM-killer result in sudden reboot wheras this issue result in temporary system freeze.