[gentoo-user] Re: gigabyte mobo latency

[James]

thegeezer <thegeezer <at> thegeezer.net> writes:

> especially for non-local systems.  other distros have apps such as
> "cgclassify" which provides some shortcut to managing cgroups --
> creation / and moving process in and out

Ok. So, if you or anyone else knows of or runs across a robust gui
managment interface for cgroups, please post to this list or drop
me some email. Porting something that is established is my preferred
modis_operandi.....




> you can also have a nohup process that does ps -eLf to search for
> process you want to classify and move them into the appropriate cgroup
> for default cgroups you can also use inotify
> a quick search shows http://libcg.sourceforge.net/ which daemonises this
> process.

Yes well this is fantastic information. I've read dozens and dozens
of things about cgroups, but none more useful than what you have 
stated here. So now I'm on the path to finding something to port to
gentoo/openrc/cgroups or something to hack to fill this void().
The only FSM (Finite State Machine) development software I see in
portage is qfsm. I'm off to look for a new FSM design software package;
as an 'old_fart' it seems logical that limited physical resources
should have finite states and therefore be first designed as a FSM.
I feel 'cheated" that after quickly looking at about a dozen books on
deep issues with 'C" on unix, that none mentioned cgroups. I feel,
stupid and ignoranat and orphaned because this wonderful technology,
cgroups, has been pretty well hidden?  A gui interface to a FSM instantiated
control system for cgroups, appears to be to be a very cool idea. It's going
to be a prerequisite for robust linux clustering, imho. FSMs are the best
way to manage finite hardware resources and they are the mainstay of
traditional device (hardware) driver codes. [1]


> all this is a bit hack'n'slash though i appreciate, so if anyone else
> knows of suitable tools i'd also be interested to hear of them


I've done quite a bit of reading and research. There is much "high_brow"
talk (chatter) about cgroups but very little on a practical, useful basis. 
I sense there are many more folks just like us that need a robust,
easy to follow methodology to learn about, setup and master cgroups.
Even if we all end up migrating to systemd (which from plentiful complaints
from many very bright folks about  the net and the lack of a clean, useful
documentation on systemd, it's likely to be a decade before systemd
stablizes and folks produce sufficiently useful documentation and examples)
cgroups does illuminate how things should work in a complex environment so
it still is worth it's weight in gold, before one attempts to master the
(systemd) beast. 

Your information about cgroups is WONDERFUL!

thx,
James 

[1] http://en.wikipedia.org/wiki/Finite-state_machine#Software_applications

[2] http://sourceforge.net/projects/fsmdesigner/

[3] http://www.typesafe.com/activator/template/akka-sample-fsm-scala

[4] https://wiki.python.org/moin/FiniteStateMachine