LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Desktop (http://www.linuxquestions.org/questions/linux-desktop-74/)
-   -   Gnome stuttering, disk I/O, and weird mount options (http://www.linuxquestions.org/questions/linux-desktop-74/gnome-stuttering-disk-i-o-and-weird-mount-options-4175462459/)

Gullible Jones 05-18-2013 07:57 AM

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?

edorig 05-18-2013 10:00 AM

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).

Gullible Jones 05-18-2013 02:03 PM

Quote:

Originally Posted by edorig (Post 4953721)
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.

Gullible Jones 05-18-2013 04:14 PM

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?


All times are GMT -5. The time now is 06:22 AM.