Talk:Improving performance

From ArchWiki
Jump to: navigation, search

Watchdog section

I've added a watchdogs section. Tell me what do you think about? --nTia89 (talk) 10:42, 29 December 2016 (UTC)

Is it really recommended to disable watchdog services? See watchdog(8). Even when running a 'simple' desktop, it needs to monitor a lot of things. Don't forget most MB use a watchdog service. How to know this is really safe? Francoism (talk) 10:52, 29 December 2016 (UTC)
1. I've never had a problem, see also: https://bbs.archlinux.org/viewtopic.php?id=163768 --nTia89 (talk) 11:01, 29 December 2016 (UTC)
2. Your watchdog is related to the specific program watchdog (https://www.archlinux.org/packages/extra/x86_64/watchdog/), a standalone program, not installed by default, not dependency of other packages. --nTia89 (talk) 11:05, 29 December 2016 (UTC)
You are correct about the watchdog package, but it is just to give you an example of what a watchdog does. It also depends on the hardware and software that's in use. To give you an example, an USB device that causes issues, will be unable to recover if no watchdog is in use. It can also lead to unexpected reboots (a watchdog is able to perform recovery operations) and maybe even hardware damage (see temperature monitoring). The one in the kernel are linked with the CPU/MB it seems, think they are created for some reason. ;) Francoism (talk) 11:13, 29 December 2016 (UTC)
No, I don't think so. Low-level hardware interrupt are handled by low-level software, the BIOS/EFI.
For what watchdogs do, read the first and third link.
I'm with you that "if it exists, there is a good reason, so...", but this doesn't mean everybody need it.
PS: What I've written on the wiki is the sum/product of what I have understand/learn about kernel watchdog; an issue started time ago while for the first time I've read about "NMI_watchdog" in the dmesg; the links provided at the end of my edit are the sources from which I extrapolated those information; if you have other sources, share, I'm here to learn in primis. --nTia89 (talk) 14:54, 29 December 2016 (UTC)
Here is what I get from time to time after plugging someting into my only USB3 port. After that happens, I need to reboot to make it work again. It's definitely tied up to the hardware driver and I'm not really interested in finding out what might happen without the watchdog. -- Lahwaacz (talk) 16:42, 29 December 2016 (UTC)
Please, explain better your experience, because if you get an hardware problem that stuck your system, the watchdog should recognize this situation and it will automatically reboot the system. Without a watchdog the stuck system will continue to go (even if stuck) until you manually reboot your machine. This is the purpose of a watchdog. This is why it is not a mandatory piece of a laptop/desktop system where user can operate manually (while the user can do this in an embedded device...). --nTia89 (talk) 16:53, 29 December 2016 (UTC)
Unless you have set RuntimeWatchdogSec in /etc/systemd/system.conf, watchdog is not doing anything for you in this case. All watchdog does in an Arch install by default is check if a shutdown has proceeded properly after 10 minutes (ShutdownWatchdogSec=10m). -- Rdeckard (talk) 21:06, 30 December 2016 (UTC)
Since you've put it on the Improving performance page, what is the performance improvement in practice? -- Lahwaacz (talk) 11:30, 29 December 2016 (UTC)
I recorded a decrease in boot and shutdown time of about 0.1 sec over a 2.0 secs boot (systemd-analyze);
both hardware and software watchdogs are disabled; the later is 'software', so I believe it "consumes" CPU...I have no evidence about it. If you have it, share here
PS: What I've written on the wiki is the sum/product of what I have understand/learn about kernel watchdog; an issue started time ago while for the first time I've read about "NMI_watchdog" in the dmesg; the links provided at the end of my edit are the sources from which I extrapolated those information; if you have other sources, share, I'm here to learn in primis. --nTia89 (talk) 14:54, 29 December 2016 (UTC)
And how does that difference compare to the standard deviation of your measured data? -- Lahwaacz (talk) 16:42, 29 December 2016 (UTC)
These are already mean values and they are enough for me. If you have an easy way to compute a more detailed report, please tell me. Or better, try by yourself and share your results! --nTia89 (talk) 16:53, 29 December 2016 (UTC)
I like the section and think it should be added somewhere in the Wiki. I think for now this is a reasonable place since the focus is on disabling something that may be consuming resources unnecessarily. Additionally at least 1 user has reported that the nowatchdog kernel parameter did not work for them [1] and that blacklisting the module was the only way to disable watchdog. -- Rdeckard (talk) 14:18, 30 December 2016 (UTC)
Thank you, I will update the section accordingly --nTia89 (talk) 14:24, 30 December 2016 (UTC)

Tuning IO schedulers

Following the bug tracker and as follow https://bugs.archlinux.org/task/54964 in last page spacecase mention that aparently elevator look depreciated. checking zen kernel show only elevators for noop, deadline & cfq but not the famous bfq, whis until 4.11 was available on normal disk. Aparently when they merged bfq the kernel fsck it up so so much that only work on ssd? I think based on that evidence that the section "Tuning IO schedulers" is now poorly writter, not reflect "modern" usage not mention correctly what to do if one want bfq on a hdd neither mention why was bfq removed or if there a patch or something to reenable. It have place for improvenment like this, but at this point it look better to "split" it into rotating hdd io scheduling performance and improvements and ssd only with a brief explanation why is split and the concecuences of using ssd performances or scheduler on rotating and viseversa.

—This unsigned comment is by Jristz (talk) 06:32, 17 August 2017‎. Please sign your posts with ~~~~!

Since 4.12, bfq is only available if blk-mq is enabled by adding scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y to the kernel command line when booting. Even then, elevator=bfq doesn't work, but it's possible to enable it with a udev rule. This change seems to be related to bfq being adopted in the standard kernel. Pdc (talk) 16:56, 17 August 2017 (UTC)
Update to my previous answer: From version 4.13, linux-zen includes a single queue version of the bfq scheduler, bfq-sq. That is the default scheduler when liunx-zen is booted without the scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y options. The standard kernel still only has the multiqueue version of bfq.--Pdc (talk) 16:27, 29 September 2017 (UTC)
There is also at least one inaccuracy: using blk-mq does not prevent the use of a scheduler. There is official support for mq-deadline, kyber and bfq.
Ruoccan (talk) 15:21, 22 October 2017 (UTC)‎

ZRam

Is this section still accurate?

"The package zramswapAUR provides an automated script for setting up such swap devices with optimal settings for your system (such as RAM size and CPU core number). The script creates one zram device per CPU core with a total space equivalent to the RAM available, so you will have a compressed swap with higher priority than regular swap, which will utilize multiple CPU cores for compressing data."

According to the Linux Kernel docs [2] "ZRAM will always allocate multiple compression streams - one per online CPUs - thus allowing several concurrent compression operations". On the gentoo wiki making multiple devices to get scaling is mentioned as a workaround for pre 3.15 kernels. https://wiki.gentoo.org/wiki/Zram#Caveats.2FCons

—This unsigned comment is by Smasher816 (talk) 00:08, 10 October 2017‎. Please sign your posts with ~~~~!