possibly poor disk performance after Slackware 15.0 upgrade
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Bumping this thread in case somebody might have some new insight into this.
For the past 7 months i've just been putting up with what appears to be really poor disk throughput on my new Slackware 15.0 install. My primary hard drive is mainly affected by this. External USB hard drives appear to have better performance. And just today, i decided to watch a DVD using an external DVD-ROM drive. The drive throughput according to gkrellm maxes out at 1 MB/s, my DVDs are unwatchable. The video player i'm using is xine. CPU usage is low.
Since you'd previously been running 11.0, I'm going to assume that your installation is 32-bit.
Bumping this thread in case somebody might have some new insight into this.
For the past 7 months i've just been putting up with what appears to be really poor disk throughput on my new Slackware 15.0 install. My primary hard drive is mainly affected by this. External USB hard drives appear to have better performance. And just today, i decided to watch a DVD using an external DVD-ROM drive. The drive throughput according to gkrellm maxes out at 1 MB/s, my DVDs are unwatchable. The video player i'm using is xine. CPU usage is low.
I don't know what else i could possibly check. I've compiled and recompiled the kernel. The cpufreq governor is set to "conservative", but even "performance" does nothing, only makes the CPU run hotter.
I'm thinking of downgrading the kernel to the version that i used the longest on this machine, 2.6.31. Will this work on such a new distribution?
When I upgraded to slackware64-15.0, which uses linux kernel 5.15.x, I also experienced really poor disk throughput on my disks. I'm not sure if it matters, but my disks are configured as:
gpt (partitions for small boot disk + large root disk on 8x1TB HDDs)
raid1+raid6 (8-member raid1 for unencrypted boot, 8-member raid6 for encrypted main system/root disk)
luks (encryption layer on raid6 disk)
lvm (logical volumes on raid6\luks disk, in which actual root and swap disks are made)
ext4 (filesystem used on raid1 boot disk and root LV disk; I also have a 32+GB swap LV but with 32GB ram it is not used much)
To fix my problem, I have been running linux kernel 5.10.x on slackware64-15.0. For some reason, 5.10.x is not slow like 5.15.x. Also, 5.10.x has long term support until Dec 2026, while 5.15.x support ends Oct 2023. Try using 5.10.x. I compile a custom kernel based on the slackware .config for generic 5.15.x, then "trimmed" of at least many driver/modules I know I do not need. I compile in most of the drivers that I need, especially modules for hard disk controller and network card. ALSA audio is modular, and my sensors module is modular because I load it with kernel parameter in /etc/modprobe.d/.
I just checked /var/log/messages. ata1 is running at full speed of 1.5 Gbps.
Do you think this could be related to the kernel build? For example, missing a driver or a config option that ended up causing things to run at a lower speed? Recently i found out that i forgot to include the ATA SFF chipset drivers when i needed to use the built-in CD-ROM and it wouldn't work, and i saw that ATA SFF included support for ICH8 SATA. Excitedly i recompiled the kernel with the ATA SFF drivers, hoping that things would go back to normal, but nothing. Alternatively, could i have included a driver or config option that's somehow causing conflicts and causing the lower speed?
ADD: I grabbed the installers for kernel 2.6.37.6 from Slack 13.37. I'm having trouble compiling 2.6.39 on my stock gcc.
ADD: Well shit. I got the "FATAL: kernel too old" panic when i booted up 2.6.37.6.
No I don't think there would be a serious regression or missing driver in the kernel. But to take the guess work out of setting up your own config, you could take the kernel packages from each release of slackware and carefully install each version in parallel with your slackware 15 kernel and try each one to hopefully find one that "works". BTW, are you compiling your own kernels? And I'm also curious if you are running in 32-bit mode.
When I upgraded to slackware64-15.0, which uses linux kernel 5.15.x, I also experienced really poor disk throughput on my disks. I'm not sure if it matters, but my disks are configured as:
gpt (partitions for small boot disk + large root disk on 8x1TB HDDs)
raid1+raid6 (8-member raid1 for unencrypted boot, 8-member raid6 for encrypted main system/root disk)
luks (encryption layer on raid6 disk)
lvm (logical volumes on raid6\luks disk, in which actual root and swap disks are made)
ext4 (filesystem used on raid1 boot disk and root LV disk; I also have a 32+GB swap LV but with 32GB ram it is not used much)
To fix my problem, I have been running linux kernel 5.10.x on slackware64-15.0. For some reason, 5.10.x is not slow like 5.15.x. Also, 5.10.x has long term support until Dec 2026, while 5.15.x support ends Oct 2023. Try using 5.10.x. I compile a custom kernel based on the slackware .config for generic 5.15.x, then "trimmed" of at least many driver/modules I know I do not need. I compile in most of the drivers that I need, especially modules for hard disk controller and network card. ALSA audio is modular, and my sensors module is modular because I load it with kernel parameter in /etc/modprobe.d/.
Finally, somebody else with a similar problem. I'll try a 5.10.x based on your recommendation and report back, thank you.
My disk config is way simpler than yours, just 3 MBR partitions:
Code:
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 62508914 62508852 29.8G 7 HPFS/NTFS/exFAT
/dev/sda2 62508915 70332569 7823655 3.7G 82 Linux swap
/dev/sda3 70332570 488392064 418059495 199.3G 83 Linux
No I don't think there would be a serious regression or missing driver in the kernel. But to take the guess work out of setting up your own config, you could take the kernel packages from each release of slackware and carefully install each version in parallel with your slackware 15 kernel and try each one to hopefully find one that "works". BTW, are you compiling your own kernels? And I'm also curious if you are running in 32-bit mode.
For a few days after install, i just used the stock huge-smp kernels and modules. Performance was somewhat worse and i thought a recompile with CPU optimizations, built-in drivers rather than modules, etc., would improve performance. Given that 15.0 glibc threw a "kernel too old" panic, i suppose trying the older releases won't work?
I've been running my self-built kernels from day 1 since 1999. This 15.0 install is 32-bit.
This thread is interesting because I am running ext4 on 5.15.y and I've noticed odd, periodic pauses when running a few SlackBuilds with many files.
For example, kernel-firmware.SlackBuild and kernel-modules.SlackBuild.
I have been ignoring it, thinking I would eventually get around to tuning my System for the ext4 FileSyatems on my NVMe Drives.
This morning I gathered a concrete example showing the pauses when running the Slackware64 15.0 kernel-firmware.SlackBuild.
I don't want to pollute yanyan's Thread with a lot of semi-off-topic stuff so I could open another thread -- Linux 5.15 and ext4 Performance.
Or should I post my logs here ?
Thanks for this thread yanyan !
-- kjh
Go ahead and post your tests and findings here. The thread title after all is "possibly poor disk performance after Slackware 15.0 upgrade." Perhaps other people with similar problems but didn't know it would find this thread. It would be interesting to see if your problem is ext4-related; for all we know the problem is in the block layer, for example. Or AHCI. Or FS. It could be anywhere.
This post may be related to yanyan's performance issue.
I've noticed odd, periodic pauses when running a few SlackBuilds with many files.
For example, kernel-firmware.SlackBuild and kernel-modules.SlackBuild exhibit odd pauses.
I have been ignoring it, thinking I would get around to tuning my System for the ext4 FileSystems my NVMe Drives.
Here is a concrete Example from this morning.
I use the official kernel-firmware.SlackBuild quite frequently to rebuild and update my kernel-firmware.
Script #1 below is a Log Wrapper for Pat's kernel-firmware.SlackBuild. It unbuffers the output and prefixes each line of output with a timestamp and writes to a log.
Note: I see very-similar delays without the log-wrapper so the delays are not related to the logging ...
Script #2 below is a gawk script to find and print the delays in the LogFile from Script #1.
This is the output from Script #2. Note the delays between the pairs of Adjacent Rows in the LogFile.
Colon-Delimited:
Col[1] is the row number in the log
Col[2] is the seconds since the epoch
Col[3] is the log line from kernel-firmware.SlackBuild
I wonder now if this could be an issue with the ext4 module in the 5.15 Kernel ?
-- kjh
Script #1 - write kernel-firmware.SlackBuild output to a log with timestamps.
Code:
#!/bin/sh
DoName="kernel-firmware.SlackBuild"
LogNam="$DoName.log"
echo "$0 startup at `date`" |tee $LogNam
unbuffer ./$DoName 2>&1 |gawk '{ printf( "%d: %s\n", systime( ), $0 )}' |tee -a $LogNam
RetCode=$?
echo "$0 complete at `date` ... RetCode = $RetCode" |tee -a $LogNam
exit $RetCode
Script #2 - Find Delays .gt. 1-sec in the LogFile
Code:
gawk '
BEGIN{
FS = ":"
N = T = P = 0
M = 1
L = ""
}
{
N ++
T = $1+0
if ( T != P )
{
if (( T != P+1 ) && ( L != "" ))
{
printf( "%6d:%s\n",M,L )
printf( "%6d:%s\n",N,$0 )
}
P = T
}
M = N
L = $0
}' kernel-firmware.SlackBuild.log
This post may be related to yanyan's performance issue.
I've noticed odd, periodic pauses when running a few SlackBuilds with many files.
For example, kernel-firmware.SlackBuild and kernel-modules.SlackBuild exhibit odd pauses.
I have been ignoring it, thinking I would get around to tuning my System for the ext4 FileSystems my NVMe Drives.
Here is a concrete Example from this morning.
I use the official kernel-firmware.SlackBuild quite frequently to rebuild and update my kernel-firmware.
Do you have a 32-bit kernel as well?
Funny, two days ago I was tar xvf'ing the kernel-firmare.txz from Pat that just came out and noticed a pause. But it was not a long pause. It was maybe under 5 seconds. It was not a bad kind of pause. I just figured it was the specific file. Yes when I had the other power supply in, it would pause, once or twice after a while, and got progressively worse and eventually the system would essentially grind to a halt when using the disk. With this other power supply, and neither of you seem to have a hardware issue; I think we have ruled out a hardware issue.
When I was trying to isolate the problem I had earlier this year, I booted different live cds, loading straight to ram, and then I would dd the content of the hard disk over to a usb drive that I knew had no problem, being on a different bus and power supply. I liked this method because it kept the main hard drive read only, and just reading from the drive was enough to cause resets on the SATA bus which I would notice based on the time it took to copy 500GB. So I would try different things (including kernel versions), and I did read over potential ext4 problems and switches, but none of those made a difference. I performed the same tasks trying different hardware configurations too, which, was found to be the power supply. I also rebooted and reattempted the test several times to make sure the test was telling me I found the problem or not. But by that time, the test was probably 95% reliable on finding a SATA reset on each pass.
So I don't suspect ext4 problems in this kernel. I find the ext3->ext4 upgrade interesting, but I don't see how it would trigger any issue. For me I installed ext4 on this drive for a 64-bit install of slackware 14.1 when I switched to 64-bit finally in 2017.
I might try to unzip the kernel-firmware some, but I'm afraid that the disk caching might change the result.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
