Dne 25. 05. 23 v 1:47 Demi Marie Obenour napsal(a):
On 5/24/23 08:44, Zdenek Kabelac wrote:
Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a):
I noticed that by default, Qubes OS has voluntary kernel preemption
as opposed to full preemption. I found that enabling full preemption
(preempt=full on kernel command line) makes the system significantly
more responsive under heavy I/O load. In particular, if I build a
kernel in a Qubes OS VM, it significantly degrades responsiveness
without preempt=full. With preempt=full, the system remains
responsive. The storage stack used is LVM thin provisioning on LUKS,
and I have observed significant CPU usage in dom0 kernel threads with
names that indicate they are related to dm-thin and dm-crypt.
The kernel config used by the Qubes kernel package I use (6.1.28) is
based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd)
indicated that the same arguments apply to Fedora. Therefore, I am
asking if Fedora should use full kernel preemption by default.
Hi Demi
Could you please provide 'dmsetup table' - so we could see how doe your
device stack looks like ?
The output of 'dmsetup table' contains all qube names so I would prefer to not
post it publicly. The device stack is NVMe -> crypt -> linear -> thin pool -> thin.
Hi
You could always 'anonymize' table names with awk/python/perl/sed - aka just
leave there first letter - names are not important - rather the content of
table line itself and the complexity of device stack. There are some limits
over which the active usage of thins may degrade the performance of the system.
But it's always easier to see & reproduce on some user's data.
So just unify/mange/anonymize the names - but tables would be interesting to see.
You may also add 'dmsetup info -c' & lsblk
Regards
Zdenek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
