Rolling back Intel-microcode updates and computer speed
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
I assume that Debian package intel-microcode packages gradually correct the various spectre and meltdown issues. From what I understand about these problems, the only way to correct them on existing processors is to disable the speculative execution (or what it is called) and consequently to reduce performance (it is not clear to me in percentages how big, but I read some speculation that it car reach several percent even more than 10%)
Is there any way to bring those updates to the cpu firmware back if I do not care about spectre or meltdown issues (and I frankly do not on certain computers that are dedicated only to calculations and the only way the internet is used there is to install and update packages) to maximize the performance?
debian cpu intel firmware
asked Aug 23 at 23:39
leosenko
1626
add a comment |Â
up vote
4
down vote
favorite
I assume that Debian package intel-microcode packages gradually correct the various spectre and meltdown issues. From what I understand about these problems, the only way to correct them on existing processors is to disable the speculative execution (or what it is called) and consequently to reduce performance (it is not clear to me in percentages how big, but I read some speculation that it car reach several percent even more than 10%)
Is there any way to bring those updates to the cpu firmware back if I do not care about spectre or meltdown issues (and I frankly do not on certain computers that are dedicated only to calculations and the only way the internet is used there is to install and update packages) to maximize the performance?
debian cpu intel firmware
asked Aug 23 at 23:39
leosenko
1626
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I assume that Debian package intel-microcode packages gradually correct the various spectre and meltdown issues. From what I understand about these problems, the only way to correct them on existing processors is to disable the speculative execution (or what it is called) and consequently to reduce performance (it is not clear to me in percentages how big, but I read some speculation that it car reach several percent even more than 10%)
Is there any way to bring those updates to the cpu firmware back if I do not care about spectre or meltdown issues (and I frankly do not on certain computers that are dedicated only to calculations and the only way the internet is used there is to install and update packages) to maximize the performance?
debian cpu intel firmware
asked Aug 23 at 23:39
leosenko
1626
I assume that Debian package intel-microcode packages gradually correct the various spectre and meltdown issues. From what I understand about these problems, the only way to correct them on existing processors is to disable the speculative execution (or what it is called) and consequently to reduce performance (it is not clear to me in percentages how big, but I read some speculation that it car reach several percent even more than 10%)
Is there any way to bring those updates to the cpu firmware back if I do not care about spectre or meltdown issues (and I frankly do not on certain computers that are dedicated only to calculations and the only way the internet is used there is to install and update packages) to maximize the performance?
debian cpu intel firmware
debian cpu intel firmware
asked Aug 23 at 23:39
leosenko
1626
asked Aug 23 at 23:39
leosenko
1626
asked Aug 23 at 23:39
leosenko
1626
asked Aug 23 at 23:39
leosenko
1626
asked Aug 23 at 23:39
leosenko
1626
1626
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
6
down vote
If you solely get your microcode from intel-microcode, uninstalling it will get rid of the low-level Spectre patches. However, note that this won't prevent firmware (EFI or BIOS) from loading its own microcode updates before the OS boots.
To check if Spectre patches are enabled, you can observe the contents of the files in /sys/devices/system/cpu/vulnerabilities to see what the kernel thinks. There is also a third-party script that provides detailed information: https://github.com/speed47/spectre-meltdown-checker
Also consider adding spectre_v2=off to the kernel command line.
Do consider running benchmarks to confirm perceived changes in system performance. If the impact of the microcode patches turn out to be negligible, it won't hurt to leave them.
answered Aug 24 at 0:04
dsstorefile1
1,721212
1
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
If you solely get your microcode from intel-microcode, uninstalling it will get rid of the low-level Spectre patches. However, note that this won't prevent firmware (EFI or BIOS) from loading its own microcode updates before the OS boots.
To check if Spectre patches are enabled, you can observe the contents of the files in /sys/devices/system/cpu/vulnerabilities to see what the kernel thinks. There is also a third-party script that provides detailed information: https://github.com/speed47/spectre-meltdown-checker
Also consider adding spectre_v2=off to the kernel command line.
Do consider running benchmarks to confirm perceived changes in system performance. If the impact of the microcode patches turn out to be negligible, it won't hurt to leave them.
answered Aug 24 at 0:04
dsstorefile1
1,721212
1
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
add a comment |Â
up vote
6
down vote
If you solely get your microcode from intel-microcode, uninstalling it will get rid of the low-level Spectre patches. However, note that this won't prevent firmware (EFI or BIOS) from loading its own microcode updates before the OS boots.
To check if Spectre patches are enabled, you can observe the contents of the files in /sys/devices/system/cpu/vulnerabilities to see what the kernel thinks. There is also a third-party script that provides detailed information: https://github.com/speed47/spectre-meltdown-checker
Also consider adding spectre_v2=off to the kernel command line.
Do consider running benchmarks to confirm perceived changes in system performance. If the impact of the microcode patches turn out to be negligible, it won't hurt to leave them.
answered Aug 24 at 0:04
dsstorefile1
1,721212
1
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
add a comment |Â
up vote
6
down vote
up vote
6
down vote
If you solely get your microcode from intel-microcode, uninstalling it will get rid of the low-level Spectre patches. However, note that this won't prevent firmware (EFI or BIOS) from loading its own microcode updates before the OS boots.
To check if Spectre patches are enabled, you can observe the contents of the files in /sys/devices/system/cpu/vulnerabilities to see what the kernel thinks. There is also a third-party script that provides detailed information: https://github.com/speed47/spectre-meltdown-checker
Also consider adding spectre_v2=off to the kernel command line.
Do consider running benchmarks to confirm perceived changes in system performance. If the impact of the microcode patches turn out to be negligible, it won't hurt to leave them.
answered Aug 24 at 0:04
dsstorefile1
1,721212
If you solely get your microcode from intel-microcode, uninstalling it will get rid of the low-level Spectre patches. However, note that this won't prevent firmware (EFI or BIOS) from loading its own microcode updates before the OS boots.
To check if Spectre patches are enabled, you can observe the contents of the files in /sys/devices/system/cpu/vulnerabilities to see what the kernel thinks. There is also a third-party script that provides detailed information: https://github.com/speed47/spectre-meltdown-checker
Also consider adding spectre_v2=off to the kernel command line.
Do consider running benchmarks to confirm perceived changes in system performance. If the impact of the microcode patches turn out to be negligible, it won't hurt to leave them.
answered Aug 24 at 0:04
dsstorefile1
1,721212
answered Aug 24 at 0:04
dsstorefile1
1,721212
answered Aug 24 at 0:04
dsstorefile1
1,721212
answered Aug 24 at 0:04
dsstorefile1
1,721212
1,721212
1
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
add a comment |Â
1
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
1
1
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
On the subject of benchmarks: the kerfuffle during the past few days over Intel's new non-free software licence for its microcode initially prohibiting the publication of processor benchmarks has drawn attention to the fact that this is not free software and Debian bug #906158. So maybe the questioner might not want to run the software on principle as well. Some people do make that choice. It's thus not quite as simple as "it won't hurt".
– JdeBP
Aug 24 at 10:04
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f464532%2frolling-back-intel-microcode-updates-and-computer-speed%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
