Page 1 of 1

swapping, performance, and distro choice

Posted: 17. Jan 2013, 05:15
by GJones
So I'm just testing PCLinuxOS 2012.12 on my laptop. I am not particularly fond of it, or of the distro in general, but I must acknowledge that it is very very fast.

Part of that I guess is due to the BFS kernel. And part of it is undoubtedly due to KDE having a lot of stuff disabled. But I've noticed a broader pattern, which I think comes into play here. Some distros are a lot slower than others, in a very obvious, describable way: they're more swappy, even with the same vm.swappiness setting.

On Slackware, Debian, CentOS, and PCLOS (and their descendents): swapping only occurs under significant load. If you have 2+ GB of RAM then you will not see your OS start swapping, unless you start playing 3D games or copying huge files or something.

On Ubuntu, OpenSUSE, Fedora, and Mandriva/Mageia: swapping starts soon after you log in. Package management in particular causes lots of swapping, but even having too many browser tabs open will start eating into swap space; and performance is correspondingly bad. Furthermore, reducing the vm.swappiness sysctl reduces swapping only a little, if at all.

There is almost a pattern here. OpenSUSE, Fedora, and Mageia all use systemd, and therefore have to have the cgroup FS mounted... But Ubuntu doesn't. So I'm not sure exactly what's going on. Also, Arch Linux uses systemd now, and doesn't seem to suffer from particularly bad performance.

I'm kind of perplexed. My suspicion is that this has something to do with the way desktops are set up, because while Ubuntu (and Kubuntu, and Xubuntu) all swap a lot, customized Ubuntu installations (via the server or minimal install CD) work okay; and using e.g. Fluxbox on one of the offending distros, instead of the default desktop choice, nullifies the problem. But I'm not sure what services, or whatever, would be responsible for causing unneeded swapping.

Has anyone else observed this? What do you people think?

Re: swapping, performance, and distro choice

Posted: 21. Jan 2013, 04:18
by sqlpython
Just adding my installs and what I observe for your information..
Firstly, PClinuxOS is a nice Beginners Feature Packed Linux OS. Heavy on the Hard Disk Real Estate.
However as I have run it live and installed it, I never found it particularly fast, maybe average speed.
One users Average speed may be another Users very very fast speed though.

I run Debian (Wheezy & Sid), Salix 13.1, Arch, & Gentoo.. Performance wise on my Thinkpad PcLinuxOS would be an Also ran.
My hardware is CPU Dual Core 2.2, 4 gb mem, 7200 rpm Hard Drive and I use a 10 gb Swap partition.
The video is a simple Intel Mobil 4..
The Wheezy Kernel is compiled to see 4 gm mem
The Sid Kernel is compiled to see 3 gb mem.
The Salix kernel see 3 gb mem.
The Arch kernel sees 4 gb mem.
The Gentoo kernel sees 4 gb mem
All have the Swap partition active and On.
Bottom line None uses the Swap. Matter of fact I never get useage to 2 gb mem... Not even playing OpenArena with many other apps open.. most of the time at 200 mb to 400 mb
Linux is very efficient.
No, While a Nice OS I don't find PClinuxOS particularly fast.

Re: swapping, performance, and distro choice

Posted: 24. Jan 2013, 23:51
by GJones
Thanks for mentioning your observations, sqlpython.

Some further notes on this:

- A member of my family uses a 2.4 GHz Pentium 4 desktop with 512 MB of RAM. Salix 13.37 Xfce performs extremely well on it.

- I am currently setting up a 2.4 GHz Pentium 4 laptop with 512 MB of RAM for another family member. I haven't tried 13.37 on it, but Salix 14.0 Xfce gives exceedingly per performance on it.

- Likewise, I briefly tried PCLOS on my netbook, and was surprised to discover that it was a poor performer.

I am developing a suspicion that some kernel versions disagree with certain hardware, rather than being generally good or bad performers.

Re: swapping, performance, and distro choice

Posted: 1. Sep 2013, 17:26
by GJones
An update... I think I have found the problem. It's not memory management; it's CPU scheduling. Specifically the sched_autogroup patch.

Boot Ubuntu 13.04 with default kernel options -> slow as hell.

Boot with 'noautogroup' -> very snappy thank you.

It looks like the issue is that autogroup being enabled makes the kernel not respect nice levels, so e.g. processes running at nice 19 still get a normal share of CPU - and probably, ones running at negative niceness aren't properly prioritized. Boo.