Gnome stuttering, disk I/O, and weird mount options
Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
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.
Gnome stuttering, disk I/O, and weird mount options
My laptop suffered a hardware failure, so for now I am using Fedora 18 with Gnome 3 on my netbook. Unfortunately the desktop experience is really... stuttery. Like watching a slideshow actually; especially when installing packages. Even typing lags a bit.
On the vague hypothesis that this might have to do with disk I/O, I tried some different mount options for my ext4 root partition:
noatime makes minimal difference. Likewise nobarrier (which I don't want alone anyway, too risky).
sync,nobarrier of course makes things slower.
Now here's where things get interesting. sync,barrier causes throughput to hit rock bottom, but desktop responsiveness goes way up; Gnome stops stuttering, yum uses less CPU power, and the netbook's fans get a lot quieter... But disk writes take about ten times longer.
Why the improved responsiveness? Does buffering chew up CPU power? If so, why does sync,nobarrier give me so much lag compared to sync,barrier?
Is there any way I can get the responsiveness of sync,barrier without killing write performance?
Or is it just a matter of throughput and latency being directly proportional?
It is difficult to answer your question. How much RAM does your computer have ? How large is your swap partition ?
Do you have a SSD or a hard drive ? When a computer slows down so dramatically, it is usually because it does not
have enough RAM and it starts to use swap (particularly slow if you don't have a SSD). If you are using a sync,barrier option for mounting your hard drive,
then maybe Linux does not use a disk cache in RAM at all, freeing more memory for your user programs. That might
be the reason why you see better performance with these options. You may try to run your netbook without X (changing /etc/inittab to limit the runlevel to 3) or change to a less memory consuming desktop (say XFCE or LXDE) to see if there is an improvement.
Another possibility is that you don't have UDMA enabled making writes very slow. You can try to use dmesg |grep UDMA to determine your drive settings or you can use hdparm (but read its manual first).
It is difficult to answer your question. How much RAM does your computer have ? How large is your swap partition ?
Do you have a SSD or a hard drive ? When a computer slows down so dramatically, it is usually because it does not
have enough RAM and it starts to use swap (particularly slow if you don't have a SSD).
1 GB RAM, 4 GB swap partition on a 160 GB HDD. It's slow even when not swapping though, despite ~400 MB worth of filesystem cache. Reducing swappiness doesn't seem to help.
Quote:
If you are using a sync,barrier option for mounting your hard drive,
then maybe Linux does not use a disk cache in RAM at all, freeing more memory for your user programs.
That did occur to me, OTOH sync alone should prevent Linux from doing any write caching in RAM. barrier/nobarrier shouldn't have any effect when sync is enabled, other than to add spurious sync attempts and thereby slow things down... No?
Quote:
That might
be the reason why you see better performance with these options. You may try to run your netbook without X (changing /etc/inittab to limit the runlevel to 3) or change to a less memory consuming desktop (say XFCE or LXDE) to see if there is an improvement.
Running CLI only is not an option ATM (and sadly may never be).
For typical use I'm actualy running Ratpoison with Gnome apps...
Quote:
Another possibility is that you don't have UDMA enabled making writes very slow. You can try to use dmesg |grep UDMA to determine your drive settings or you can use hdparm (but read its manual first).
Hard disk is configured for UDMA/133, and the BIOS is set to AHCI mode.
Okay, here is the deal: write barriers bypass the hardware write cache. This is why throughput is bad with sync,barrier. sync,nobarrier will get you the same thing if used with hdparm -W0.
On the other hand, disabling the hardware write cache and write barriers, in async mode, seems to get me decent performance. No more stuttering! It looks as though the disk write cache is somehow causing latency issues.
(I'm reminded of an old truism that one buffer will speed things up, and more will slow things down.)
So now my partitions are mounted async,noatime,nobarrier with write cache disabled on the hard disk... Now my questions with this configuration are
a) If I save a file, how long will it take to be written? Will the write start in 5 seconds or less as the commit interval supposedly dictates, or will ext4 do further caching behind my back?
b) If the computer shuts down improperly, will the filesystem stand a chance of being corrupted, as with sync,nobarrier and write cache enabled?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.