14.2 slow after update to 4.4.153
Updated 14.2 from 4.4.144 to 4.4.153. System ran slower afterwards, especially X.
This is an older system which has run slack for many years: Pentium(R) 4 CPU 3.00GHz, ATI Radeon X1650, up to date with Slack14.2 patches, and has a few X packages compiled from Slackware-Current. (No, I'm not buying a new PC. Landfills have enough digital junk already.) 4.4.144 seems to run as expected. 4.4.153 graphics in Seamonkey are especially slow. A diff on the 4.4.144 and 4.4.153 kernel configs shows nothing notable. Anyone else seen anything similar? Thanks, Halsey |
I found seamonkey slow in _anything_ I opened it in. KDE also. You'd have an old or underpowered system (like mine, or yours) on life support running those things. Are the proprietary graphics drivers loading? It might be software rendering, which is cpu intensive.
BTW +1 on the 'Landfills have enough digital junk already.' |
Quote:
And that behavior itself looks similar with what happened in the x86_64 world after implementation of protections against Spectre/Meltdown, maybe exacerbated by the low computing power of your system(s). Maybe they started to add that to the x86 too. So, my suggestion is to try to disable those (supposed) protections with "nopti" on kernel command line and see if that changes something. |
@HalseyTaylor
As Darth Vader suggested, the cause of the performance loss might come from the Intel vulnerabilities mitigations, however, in the changelog of 4.4.153 it's only describing some changes related to L1TF: https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.153 Given that your CPU is really old and according to Intel not affected by any of these newly discovered vulnerabilities, I believe it's safe for you to disable them with the help of some kernel boot parameters. Given your actual situation and the changes in 4.4.153, I'd start with disabling the L1TF mitigation: Code:
l1tf=off To disable all these new mitigations, at least on the level permitted/documented, the following kernel boot parameters are to be used: Code:
pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier https://git.kernel.org/pub/scm/linux...6adf9c1e17aa2d https://www.kernel.org/doc/html/late...lt-mitigations |
Quote:
|
Quote:
The l1tf switch is documented for the l1tf patch: https://www.kernel.org/doc/html/late...uide/l1tf.html As for no_stf_barrier, it looks like only applicable for PowerPC (I should have checked that): https://github.com/torvalds/linux/bl...nel/security.c For x86, the following will qualify: Code:
pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable |
A P4 is still post 1995 and affected by many of the vulnerabilities. It's not that old.
|
Bios date is 2006. This system's been on life support for years :) Plays Portal2 and HL2 on the XP boot side just fine.
Kernel boot parameters didn't seem to have much effect. This system sits behind NAT and has a pretty good rc.firewall. It gets turned off when not in use. It's not like it's a server facing the world. Downgrading to 4.4.88, the last slack kernel before spectre/meltdown came up, seems to work fine. Part of the problem is that with hardware acceleration, the video card is quirky (X1650 GT) with the radeon X-driver: it intermittently locks up. This usually happens when updating video, and a keyboard or USB service request comes in. So, it runs in software mode. It ran great with the FGLRX module. But, that's not been available to this card for a while. It's never been clear whether the lockups happen at the DRM level or the X driver level. It runs fine for most things so it stays out of the landfill. True, I can't view web pages creptified with tons of CSS & javascript and superfluous images. But, it displays the useful stuff well enough. Javascript is toggled off which helps a lot. |
Quote:
I used to call it with affection (or exasperation?) just "IT FREEZE!" and it appears even in more powerful boxes which are unlucky to sports a budget Radeon video-card. Was not spared even a mighty Bulldozer with 8 cores and 32GB RAM DDR3 1600MHz, but with an Radeon HD6450. And those freezes appearing on Slackware 14.2 on all my 6 AMD computers (all with budget Radeon graphics) is the reason behind the fact that I followed like a hound the Slackware 15 development cycle. Long story short, to fix those freezes you shall upgrade the graphics stack like in slackware-current, building from sources: kernel, LLVM, Mesa3D (and libDRM) and X.org (and its drivers) It is a lot of work, but you have a nice bonus above the system stability: the graphics will behave much much better and much snappy. I believe that's worth to try even with your old Pentium 4. ;) |
FWIW, I had an X1250(Slightly earlier) probably manufactured 2007, and a twin Turion, and the card was crap - I mean really crap. It couldn't lip synch on full screen video. I rebuilt with LLVM (a real pain in the butt back then) because the heads in Radeon Dev told me to: Apparently I had no vertex shader (Whatever that is). It made sod all difference.
|
2 Attachment(s)
Quote:
Anyways, the Radeon X1250 is what sports the chipset RS690 and this was on ones of motherboards well appreciated in Romania, for its 14W power consumption and decent performances with AM2 45W processors. Also, it is the chipset on Acer Veriton L410 (see the screenshot), a mini-PC which invaded Romania (as second-hand boxes) because it is very appreciated for HTPCs or small browsing/multimedia PCs, while the shops asks for crazy prices for HTPC hardware. Believe or not, in my country is cheaper to build a beast box than a HTPC. And the latest trend here is orientation to small PCs instead of overpowered beasts. :p And I am pretty sure that it works more than decent with the current graphics stack from Slackware-current, Fedora, OpenSUSE Leap or Ubuntu. Because I seen it in action, being used by many of my friends. |
Hmm... Last December, the LLVM, Mesa3D, and libDRM were upgraded using what was in -current at the time. This got glamor running on the X1650 - which it couldn't do before. Ran pretty hot, tho. But, kernel was 4.9. You're right, upgrading was a pain.
Think I'll wait for Slack15, then load it all to a new hard drive and see what happens. It's funny, going to the smaller PC's and working in the cloud. Back in my day, we called them VT-220's and they worked in the mainframe. |
Quote:
|
Quote:
|
HalseyTaylor --
If you're interested, below my sig is a script that I run after every kernel update to look for certain changes to state of the S&M Mitigation wac-a-mole game. I do understand that your post is marked [SOLVED] and that the performance regression may not be specifically related to any particular S&M Mitigation but there is some good info in the output that might help discover the status of S&M mitigations for your Pentium 4. For example. this is the output for a Celeron N3160 ... note under the 'cpuinfo' section that there is no Firmware File for the Family, Model, Stepping Values for the CPU. Code:
# ./.do-get-spectre-meltdown.sh x Code:
# ./.do-get-spectre-meltdown.sh -w -- kjh This is my /root/tmp/.do-get-spectre-meltdown.sh script ( :) please don't make fun of my coding style ( or lack thereof ) :) ) By default .do-get-spectre-meltdown.sh will spew output on the screen -AND- append the output to /root/tmp/vuln-`uname -r`.txt ( example: /root/tmp/vuln-4.4.153.txt ) The script does not create /root/tmp/ directory ( you can change line 9 if you want a different directory ) ! Invoke with ANY Arg to not append to the file ( example: .do-get-spectre-meltdown.sh -w ) I always invoke the script as root after installing and booting a new kernel. Code:
#!/bin/bash |
All times are GMT -5. The time now is 08:12 PM. |