Arch Linux

Sloshy

Member

Registered: 2010-04-15

Posts: 56

cspeed: increase system responsiveness using cgroups

Recently, there was a much-discussed kernel patch that grouped processes by the TTY/terminal they were started from so your system got extremely responsive under pressure. Then, a .bashrc implementation was made that effectively does the same thing in only a couple lines of code. I decided to take that implementation (as modified at WebUpd8) and put it in a bash daemon with options.

How it works:
Linux 2.4 added a feature called "cgroups" which let you limit the resource usage of processes by prioritization, isolation, etc. For more information, see the Wikipedia article and the ArchWiki article on it. This script uses the WebUpd8 version of a bashrc modification that uses cgroups to increase your system's responsiveness under lots of pressure (for example, compiling a kernel with 'make -j64'). Note that it WILL NOT work for processes launched from X, like in your desktop environment. You'll need to open up a new terminal window or switch to a different TTY to see a difference in responsiveness.

Instructions:
After installing, if you use Arch Linux, add "cspeed" to your daemons array in /etc/rc.conf. Then, add the following line per-user in /home/user/.bashrc or system-wide at /etc/bash.bashrc:

/bin/bash /etc/bash.cgroups

Download:
AUR: http://aur.archlinux.org/packages.php?ID=43873
Github: https://github.com/sloshy/cspeed

Any bugs, suggestions, anything would be greatly appreciated !

Last edited by Sloshy (2010-12-01 18:01:29)

hellnest

Member

From: $ dmesg | grep ATA

Registered: 2010-11-11

Posts: 194

Website

Re: cspeed: increase system responsiveness using cgroups

More explanation Plz ^o^

---

Snapping my own life
github
MyBlog

hbekel

Member

Registered: 2008-10-04

Posts: 311

Re: cspeed: increase system responsiveness using cgroups

It seems you wanted to provide an easy way of enabling cgroups. That's ok of course, but it's not really the arch way. I personally wouldn't use it. Setting up cgroups isn't that hard after all, it's just a few lines...

Here are some problems I see:

- Modifying system wide config files... ouch. A big no no, at least for me. This type of hand-holding just isn't arch. Especially when you're adding to /etc/rc.local when you should at least have used an rc-script for that.

- Dynamically creating/deleting a script below /usr/local/sbin without obvious reasons: the file is static, so it could simply be distributed (with the benefit of being properly tracked by a package manager). Note that the use of /usr/local/* is discouraged. No sane arch package installs anything there, and no arch user expects anything there unless he put it there himself.

- Testing for a verbatim line in a config file to determine whether you need to edit it isn't very reliable... what if the user accidently leaves a space somewhere on your "test line" while editing the file later on? (Interestingly, you could have tested for the existence of the cgroup_clean script, which could have justified creating it dynamically... but that would've been a hack as well)

- Using inplace editing with sed to remove those changes is just... creepy. I'd never sed -i any important file, let alone a system config file.

Some bugs/oversights: It seems you forgot a ">>" on line 80, at least that seems to be your intent there. The undo function also edits /etc/skel/.bashrc, which you never touch during -s.

Sloshy

Member

Registered: 2010-04-15

Posts: 56

Re: cspeed: increase system responsiveness using cgroups

It seems you wanted to provide an easy way of enabling cgroups. That's ok of course, but it's not really the arch way. I personally wouldn't use it. Setting up cgroups isn't that hard after all, it's just a few lines...

Yeah, it's not so hard. This is more for the lazy people who don't want to modify this on their own and get it up-and-running quickly without any PEBKAC errors.

Here are some problems I see:

- Modifying system wide config files... ouch. A big no no, at least for me. This type of hand-holding just isn't arch. Especially when you're adding to /etc/rc.local when you should at least have used an rc-script for that.

I'm going to be honest here: I'm rather new to Linux. I've only used it for a few years now, and I've used Arch for less than one. So, I wasn't sure what those were until you mentioned them right now. I'll transition it to an rc-script over the weekend.

- Dynamically creating/deleting a script below /usr/local/sbin without obvious reasons: the file is static, so it could simply be distributed (with the benefit of being properly tracked by a package manager). Note that the use of /usr/local/* is discouraged. No sane arch package installs anything there, and no arch user expects anything there unless he put it there himself.

Yeah, I'll fix that. I wasn't thinking when I made my script and didn't just pre-make this file. Thanks for pointing this out!

- Testing for a verbatim line in a config file to determine whether you need to edit it isn't very reliable... what if the user accidently leaves a space somewhere on your "test line" while editing the file later on? (Interestingly, you could have tested for the existence of the cgroup_clean script, which could have justified creating it dynamically... but that would've been a hack as well)

Hmm, good point. Maybe I could append "#cspeed" before the lines that are supposed to be there; would that work?

- Using inplace editing with sed to remove those changes is just... creepy. I'd never sed -i any important file, let alone a system config file.

Yeah, this has the potential to screw up badly. As I just said, maybe "#cspeed" could help with that.

Some bugs/oversights: It seems you forgot a ">>" on line 80, at least that seems to be your intent there. The undo function also edits /etc/skel/.bashrc, which you never touch during -s.

Good call! I did forget that; my mistake. And As for the /etc/skel/.bashrc edit, that was also a mistake; an earlier version of the script, before I pushed it to github, modified each individual user's .bashrc (and set it as the default for all new users) which, as you can imagine, is super messy. I'll remove the lines you mention .

Thank you so much for your comments; I'll fix my script up right away!

Last edited by Sloshy (2010-11-26 18:05:56)

hbekel

Member

Registered: 2008-10-04

Posts: 311

Re: cspeed: increase system responsiveness using cgroups

I'd say the cleanest way of doing this would be not to modify any system config files at all. If you look at it, you need two things:

1. Something needs to happen on boot and shutdown (mounting/umounting the cgroup stuff)

2. something needs to happen when a user starts a bash session (setup the cgroup stuff for the current process...)

Use an rc-script for 1., e.g. /etc/rc.d/cgroups. Base it on the rc-script prototype (/usr/share/pacman/rc-script.proto). Write it so that it mounts the cgroup stuff on "start" and umounts it on "stop".

This way, the user can decide how to use it, either start it manually, or simply add "cgroups" to their daemons array in rc.conf, and have it work like any other system service.

For 2., I'd create a file like /etc/bash.cgroups and instruct the user to source it from his ~/.bashrc or from /etc/bash.bashrc (to make it work for all users).

As for the cgroups_clean script, just distribute that with your package...

Now the user needs to do two things instead of one, but has greater control over what happens and his files are left untouched. It would still serve the original purpose of enabling cgroups without having to know exactly how that works...

In the end you'd have a clean package that just installs three files. You could use the post_install() hook of the package to give instructions ("add cgroups to your daemons array, source /etc/bash.cgroups from your bashrc...").

I'd use it if it was like this

Sloshy

Member

Registered: 2010-04-15

Posts: 56

Re: cspeed: increase system responsiveness using cgroups

There you go! Updated and it should work great. I inspected it and it shouldn't have any gaping flaws. You can download it at the usual location.