Re: Request for comment- tuned replacing power-profiles-daemon plan
On 06/11/2023 17:30, Allan Day wrote: Hi Kate, On Thu, Oct 5, 2023 at 8:30 AM Kate Hsuan wrote: ... By integrating power-profiles-daemon with tuned, the user can get extra features to finetune the system, and the basic feature provided by ppd can be used according to the user's demand. It also can reduce the efforts of the maintainer. ... Moreover, the detailed change proposal can be found here. https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon I just noticed that the change proposal contains the line: "We expected that the user can set those profile, tuned provided through gnome-control-panel. To minimize the information to the user, the power panel would provide a simple and advanced mode to show the power profiles. If the users want to finetune the system, they can switch to the advanced mode themselves." It's a bit unclear if this is a definite plan, a requirement, or more of a speculative ambition. However, I should probably be clear that from a GNOME design perspective, an advanced power profile settings mode would likely be a tough sell. Exposing arbitrary user-defined profiles would also pose some challenges which it might be difficult to overcome. If this change proposal does require UXD changes to GNOME, then I'd suggest reaching out to us in advance to discuss them. Wouldn't it also be logical for UPower to replace power-profiles-daemon? UPower is already integrated into GNOME Settings while tuned is not, not having an additional dependency might be nicer and beneficial for other distributions which might not have a tuned package at all. Greetings, Jelle van der Waa ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
On 19/10/2022 13:56, Vitaly Zaitsev via devel wrote: On 19/10/2022 10:31, Neal Gompa wrote: HTTPS does not help with that. It's just a transport protocol. It will. All requests will be encrypted. ISP will only see server's IP-address and its hostname (only if SNI is enabled). HTTPS does not automatically add privacy for users of mirrors. See for example the excellent Debian related website and OpenBSD presentation about how you can still identify downloaded packages even when using HTTPS. [1] https://whydoesaptnotusehttps.com/ [2] https://www.openbsd.org/papers/eurobsdcon_2018_https.pdf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The performance impact of various debug options on Fedora Rawhide debug kernels
On 03/08/2022 22:47, Adam Williamson wrote: On Sun, 2022-07-24 at 10:28 +0100, Richard W.M. Jones wrote: The current Fedora Rawhide kernels are too slow to run libguestfs tests when doing Koji builds. These run in a qemu VM, running the Rawhide kernel, emulated using software virtualization (ie. TCG). They now time out because these kernels are so slow. Until fairly recently they were slow but working. I wondered if particular debug options had a greater effect on performance, so I compiled many kernels (v5.19-rc7 from upstream) using the baseline "no debug" config, then adding each debug option that we use in turn, and measuring the performance using [1], using qemu software virtualization (TCG). The tests were run many times with warmups discarded to get the mean and standard deviation, using the hyperfine program[2]. The results are below, and not very conclusive, but some options do have a very large performance impact. NO_DEBUG is the kernel compiled with no debug options enabled (ie. the baseline). In the actual debug kernel I expect the slow downs to be multiplied together. To test that I did an extra run with all debug options enabled (ALL_DEBUG). CONFIG_PROVE_LOCKING, CONFIG_LOCK_STAT and CONFIG_DEBUG_LOCK_ALLOC were present and enabled in the kernel when it was imported into git in 2010. CONFIG_DEBUG_WW_MUTEX_SLOWPATH was turned off in the past (RHBZ#1114160). It seems to have been switched on again in 2020. CONFIG_DEBUG_KMEMLEAK seems like it was enabled in 2012. It's also possible that an existing debug option has got slower in the upstream kernel, that is, it's not that we've recently changed something in Fedora. Thanks a lot for this work, Richard! And thanks to Justin for looking at it. I would be super appreciative of anything we can do to reduce the performance hit here, as it is also an issue for openQA testing - we get noticeably more test failures due to timeouts, things taking longer than expected, or typing errors when Rawhide is on a debug kernel. In Cockpit we recently enabled rawhide testing on the testing farm and noticed similar performance issues. [1] In comparison to Fedora 36 it takes 5 minutes longer in one test scenario. So it would be great to speed that up a bit! [1] https://gitlab.com/testing-farm/general/-/issues/45 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
