Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER for Linux

Reply
 
Thread Tools Display Modes
Old 09-30-2019, 02:30 AM   #1
monty
Human being with feelings
 
monty's Avatar
 
Join Date: Dec 2015
Posts: 184
Default Kernel tuning - Turning off CPU exploit mitigation

Turning off CPU exploit mitigations improves performance (sometimes up to 50%).

Warning: Do not apply this setting without considering the vulnerabilities it opens up.
https://phoronix.com/scan.php?page=n...-Spec-Switches
https://linuxreviews.org/HOWTO_make_..._on_Intel_CPUs

Code:
sudo nano /etc/default/grub
change GRUB_CMDLINE_LINUX_DEFAULT to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs clocksource=hpet mitigations=off"

sudo update-initramfs -u
sudo update-grub
__________________
KDENeon (5.0.0-32-lowlatency) AMD FX-8350, 16GB, GT 630 (nvidia-435), Multiscreen (2x 22", 1x 15"), Reaper (latest) Theme: iLogic Next, Interface: Tascam US-16x08, ControlSurface: Tascam US-2400, Monitors: JBL 4412A, Tascam VL-S3 & Alesis Elevate 3 mkII
monty is offline   Reply With Quote
Old 09-30-2019, 10:46 AM   #2
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,796
Default

I'd avoid the "clocksource=hpet" part. The kernel has very clever code to determine what the best clock source is, and often chooses TSC.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040,etc. :)
Jack Winter is offline   Reply With Quote
Old 09-30-2019, 10:59 AM   #3
monty
Human being with feelings
 
monty's Avatar
 
Join Date: Dec 2015
Posts: 184
Default

Quote:
Originally Posted by Jack Winter View Post
I'd avoid the "clocksource=hpet" part. The kernel has very clever code to determine what the best clock source is, and often chooses TSC.
ouh, will try without the hpet option, thanks for your suggestion!
__________________
KDENeon (5.0.0-32-lowlatency) AMD FX-8350, 16GB, GT 630 (nvidia-435), Multiscreen (2x 22", 1x 15"), Reaper (latest) Theme: iLogic Next, Interface: Tascam US-16x08, ControlSurface: Tascam US-2400, Monitors: JBL 4412A, Tascam VL-S3 & Alesis Elevate 3 mkII
monty is offline   Reply With Quote
Old 09-30-2019, 11:08 AM   #4
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,796
Default

Well I don't know if it has some function together with disabling the other exploits, nor do I know if it has any practical performance implication when using reaper.

Still the kernel does a lot of testing to determine the best clock source to use, and if TSC works as it should, then it's preferable to using hpet.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040,etc. :)
Jack Winter is offline   Reply With Quote
Old 09-30-2019, 11:24 PM   #5
monty
Human being with feelings
 
monty's Avatar
 
Join Date: Dec 2015
Posts: 184
Default

Quote:
Originally Posted by Jack Winter View Post
I'd avoid the "clocksource=hpet" part. The kernel has very clever code to determine what the best clock source is, and often chooses TSC.
yes, the kernel has switched to TSC after removing the hpet parameter
Code:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
the VST seem to open slightly faster ... but I still have to use a high buffer size for the VSTs otherwise I see many xruns ... only with the VST plugins.
__________________
KDENeon (5.0.0-32-lowlatency) AMD FX-8350, 16GB, GT 630 (nvidia-435), Multiscreen (2x 22", 1x 15"), Reaper (latest) Theme: iLogic Next, Interface: Tascam US-16x08, ControlSurface: Tascam US-2400, Monitors: JBL 4412A, Tascam VL-S3 & Alesis Elevate 3 mkII
monty is offline   Reply With Quote
Old 09-30-2019, 11:33 PM   #6
monty
Human being with feelings
 
monty's Avatar
 
Join Date: Dec 2015
Posts: 184
Default

so I guess this part in my rc.local should be removed, because of the hpet clock is no longer in use?

Code:
echo 3072 > /proc/sys/dev/hpet/max-user-freq
__________________
KDENeon (5.0.0-32-lowlatency) AMD FX-8350, 16GB, GT 630 (nvidia-435), Multiscreen (2x 22", 1x 15"), Reaper (latest) Theme: iLogic Next, Interface: Tascam US-16x08, ControlSurface: Tascam US-2400, Monitors: JBL 4412A, Tascam VL-S3 & Alesis Elevate 3 mkII
monty is offline   Reply With Quote
Old 10-03-2019, 04:01 AM   #7
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,796
Default

Yes, I think you can safely remove that.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040,etc. :)
Jack Winter is offline   Reply With Quote
Old 10-16-2019, 10:25 AM   #8
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,470
Default

I followed the instructions on that linuxreviews.org page on my studio DAW (i7-4770 with HT disabled)... Debian 4.9.0.11-rt kernel, adding "noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off" to the grub command line. Considerable performance improvement... my benchmark for compiling REAPER went from 2:26 to 1:54. Of course, I'll try not to browse the web on this computer...
Justin is offline   Reply With Quote
Old 10-16-2019, 11:42 AM   #9
Glennbo
Human being with feelings
 
Glennbo's Avatar
 
Join Date: Mar 2008
Location: Planet Earth
Posts: 4,040
Default

Quote:
Originally Posted by Justin View Post
I followed the instructions on that linuxreviews.org page on my studio DAW (i7-4770 with HT disabled)... Debian 4.9.0.11-rt kernel, adding "noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off" to the grub command line. Considerable performance improvement... my benchmark for compiling REAPER went from 2:26 to 1:54. Of course, I'll try not to browse the web on this computer...
I wonder how much improvement there would be on an AMD machine.

Disabling HT isn't necessary on an AMD, nor are the mitigations for mds, l1tf, meltdown, and speculative store bypass. Only the two Spectre variants affect AMDs, which is why I'm building a 3700X DAW as soon as the B550 chipset pops.
__________________
Glennbo
Hear My Music - Click Me!!!
--
Glennbo is offline   Reply With Quote
Old 10-16-2019, 12:14 PM   #10
SmajjL
Human being with feelings
 
SmajjL's Avatar
 
Join Date: Nov 2013
Location: Sweden
Posts: 2,129
Default

Since that stuff have been (officially) out in the open for long enough now one would hope/think Intel/AMD & Co are on it when making new hardware?

Intel’s newly announced 9-series CPUs bring a lot of exciting new features to the table, including higher clock speeds and the promise of greater gaming performance. But arguably one of the most important factors is in security. These chips are the first generation of new desktop CPUs to come with hardware fixes for the Spectre and Meltdown bugs which emerged in recent years.

http://cc.bingj.com/cache.aspx?q=int...3-5hnzfIuPMZuu
__________________
:)
SmajjL is offline   Reply With Quote
Old 10-16-2019, 12:15 PM   #11
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,470
Default

Quote:
Originally Posted by Glennbo View Post
I wonder how much improvement there would be on an AMD machine.

Disabling HT isn't necessary on an AMD, nor are the mitigations for mds, l1tf, meltdown, and speculative store bypass. Only the two Spectre variants affect AMDs, which is why I'm building a 3700X DAW as soon as the B550 chipset pops.
Dunno about the mitigations on AMD..

But re: HT -- my studio machine does a lot of live monitoring, so I disabled HT just to effectively have 4 slightly-faster cores rather than 8 slightly-slower cores (which is what HT ends up doing under heavy load).
Justin is offline   Reply With Quote
Old 10-16-2019, 12:52 PM   #12
Glennbo
Human being with feelings
 
Glennbo's Avatar
 
Join Date: Mar 2008
Location: Planet Earth
Posts: 4,040
Default

Quote:
Originally Posted by Justin View Post
Dunno about the mitigations on AMD..
My wife's machine is an AMD and Linux comes back with this on a

grep . /sys/devices/system/cpu/vulnerabilities/*

Code:
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
Quote:
But re: HT -- my studio machine does a lot of live monitoring, so I disabled HT just to effectively have 4 slightly-faster cores rather than 8 slightly-slower cores (which is what HT ends up doing under heavy load).
I also live monitor everything through REAPER in my studio. I'm currently using an Intel i5 which has no HT, and the AMD 3700X I plan to get also has no HT so I should be good to go.
__________________
Glennbo
Hear My Music - Click Me!!!
--
Glennbo is offline   Reply With Quote
Old 10-17-2019, 03:46 AM   #13
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,796
Default

FWIW, I've seen HT causing xruns while something executing would block high priority audio threads, IMO it's still probably best to disable it on a DAW (at least if it's running linux)
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040,etc. :)
Jack Winter is offline   Reply With Quote
Old 10-17-2019, 09:27 AM   #14
Glennbo
Human being with feelings
 
Glennbo's Avatar
 
Join Date: Mar 2008
Location: Planet Earth
Posts: 4,040
Default

Quote:
Originally Posted by Jack Winter View Post
FWIW, I've seen HT causing xruns while something executing would block high priority audio threads, IMO it's still probably best to disable it on a DAW (at least if it's running linux)
I had not ever pondered the effects of virtual cores on latency until Justin's post. The last machine I had with HT was a Pentium4 that's long been put out of service, but it is still a technical aspect of the inner workings of a DAW I find interesting.
__________________
Glennbo
Hear My Music - Click Me!!!
--
Glennbo is offline   Reply With Quote
Old 10-17-2019, 11:14 AM   #15
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,796
Default

I thought I had thoroughly evaluated SMT (hyperthreading), and concluded that it wasn't a problem on my cpu (i7-2600k).

I then had the case that the xorg process would occasionally consume 100% of the cpu time on a core, I noticed that when this occurred reaper's realtime cpu would go up and occasionally even so high that it caused xruns.

At this point I had already somewhat pestered Justin for months/years about suspicions that some synchronization code was wonky. He told me to turn off SMT and haleluja the problem went away.

It happens because the linux kernel assumes that it's high priority threads are running, and then schedules other threads to run on a sibling cpu. This causes the cpus to slow down, lose cache coherency, etc. In short it takes enough time away from the high priority threads to cause xruns in certain situations. If you really can't afford / don't want any xruns it's better to turn it off.

I floated an idea to one of the kernel devs about not scheduling/running another thread on a sibling cpu while the other is running a realtime thread. He thought it a good idea, but not right now. Once another experimental feature of the kernel is mature, it would be easy to implement. So maybe some day in the future we can both have our cookie and eat it.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040,etc. :)
Jack Winter is offline   Reply With Quote
Old 10-17-2019, 12:43 PM   #16
Glennbo
Human being with feelings
 
Glennbo's Avatar
 
Join Date: Mar 2008
Location: Planet Earth
Posts: 4,040
Default

I suspect that HT having an effect on realtime audio performance isn't limited to Linux, because I distinctly remember in Cakewalk's forums reading threads about disabling HT to solve performance issues. It makes sense to me after Justin's post that a synthetic core is another process, even if being done at such a low level.
__________________
Glennbo
Hear My Music - Click Me!!!
--
Glennbo is offline   Reply With Quote
Old 10-20-2019, 08:41 AM   #17
SmajjL
Human being with feelings
 
SmajjL's Avatar
 
Join Date: Nov 2013
Location: Sweden
Posts: 2,129
Default

Eum-eum.. amongst the list of *meh's bugs exploits, is also the Hyper Threading technology Itself containing a bugger if turning that ON?

If solving all of this is taking performance hits right & left, then I am curious to see a DAW bech of something AMD vs Intel locked on the same GHz, thing'ie.

Not running a company,Bank or in charge of Saab - Gripen fighterjets, but still, curious.
__________________
:)
SmajjL is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:15 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.