Difference between revisions of "Talk:Improving performance"

From ArchWiki
Jump to: navigation, search
m (LZO for btrfs: rm section - Btrfs#Compression mentions lzo, linked from Maximizing_Performance#Btrfs)
(Inaccuracy report)
 
(37 intermediate revisions by 12 users not shown)
Line 1: Line 1:
 +
== Watchdog section ==
  
 +
I've added a '''watchdogs''' section.
 +
Tell me what do you think about? --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 10:42, 29 December 2016 (UTC)
 +
:Is it really recommended to disable watchdog services? See [https://linux.die.net/man/8/watchdog 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? [[User:Francoism|Francoism]] ([[User talk: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 --[[User:NTia89|nTia89]] ([[User talk: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. --[[User:NTia89|nTia89]] ([[User talk: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. ;) [[User:Francoism|Francoism]] ([[User talk: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.  --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 14:54, 29 December 2016 (UTC)
 +
:::::[https://gist.github.com/lahwaacz/5bef7a353cd8cbe49164d2bf4efd47fa 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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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...). --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 16:53, 29 December 2016 (UTC)
 +
::::::Unless you have set {{ic|RuntimeWatchdogSec}} in {{ic|/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 ({{ic|1=ShutdownWatchdogSec=10m}}).  -- [[User:Rdeckard|Rdeckard]] ([[User_talk: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? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 14:54, 29 December 2016 (UTC)
 +
:::And how does that difference compare to the [https://en.wikipedia.org/wiki/Standard_deviation standard deviation] of your measured data? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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! --[[User:NTia89|nTia89]] ([[User talk: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 {{ic|nowatchdog}} kernel parameter did not work for them [https://bbs.archlinux.org/viewtopic.php?id=221239] and that blacklisting the module was the only way to disable watchdog.  -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:18, 30 December 2016 (UTC)
 +
::Thank you, I will update the section accordingly --[[User:NTia89|nTia89]] ([[User talk: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.
 +
 +
{{unsigned|06:32, 17 August 2017‎|Jristz}}
 +
:Since 4.12, bfq is only available if blk-mq is enabled by adding {{ic|1=scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y}} to the kernel command line when booting. Even then, {{ic|1=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. [[User:Pdc|Pdc]] ([[User talk: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 {{ic|1=scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y}} options. The standard kernel still only has the multiqueue version of bfq.--[[User:Pdc|Pdc]] ([[User talk: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.
 +
:[[User:Ruoccan|Ruoccan]] ([[User talk:Ruoccan|talk]]) 15:21, 22 October 2017 (UTC)‎
 +
 +
== ZRam ==
 +
 +
Is this section still accurate?
 +
 +
"The package {{AUR|zramswap}} 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 [https://www.kernel.org/doc/Documentation/blockdev/zram.txt] "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
 +
 +
{{unsigned|00:08, 10 October 2017‎|Smasher816}}

Latest revision as of 15:21, 22 October 2017

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 ~~~~!