On Thu, Jul 20, 2023 at 8:53 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Sat, May 20, 2023 at 06:14:17PM -0500, Justin Forbes wrote: > > On Sat, May 20, 2023 at 3:44 PM Demi Marie Obenour > > <demiobenour@xxxxxxxxx> wrote: > > > > > > 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. > > > > > For workstation, preempt=full does likely make sense, and I have been > > running it for a while. For server, maybe not so much. That is the > > joy of dynamic preempt. You can boot with preempt=full and run that > > way if you like. There is an open issue for the workstation WG to > > look at making preempt=full the default there at some point. > > What's the downside from full pre-empt that makes it inappropriate > as the defualt for Fedora server spins too ? Is it that it is > trading off overall peak performance in favour of reduced latency, > and we think servers would prefer the peak performance in general ? That is the downside. It might be interesting to ask the performance group for RHEL to run a battery against preempt=full and see what the results are. The ELN kernel does enable PREEMPT_DYNAMIC and there should already be a baseline to compare against there. I just do not know if they have space cycles to run those tests. No matter what default we choose, there are no plans to turn off PREEMPT_DYNAMIC meaning any user is free to choose the preempt mode that works best for them. I have been running preempt=full for quite some time on my desktops systems here. Justin _______________________________________________ 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
