Date: Mon, 3 Aug 2009 20:13:34 +0200 From: Edward Tomasz Napierala <trasz@FreeBSD.org> To: soc-status@freebsd.org Subject: Hierarchical Resource Limits - another progress report. Message-ID: <20090803181334.GA46526@pin.if.uz.zgora.pl>
next in thread | raw e-mail | index | archive | help
I guess it may be a good idea to sum up what I have done and what's there still to be done. Userland side of HRL is basically done. There is a tool, hrl(8) (and yes, it even has a man page!), which is simple, but it provides all the functionality I've planned. The only missing part is to use humanize_number(3) to preprocess output. There is also a rc script to load rules at system startup from /etc/hrl.conf. Syscall interface is done. There are five new system calls, that use character strings to communicate with the userland, which makes them quite extensible, so it's possible to add new resources or subjects in the future without the need of recompilation of the userland. Because most resource rules will be per-loginclass, as they are today, it was neccessary to make kernel aware of to what loginclass a given process belongs. It was implemented by adding setloginclass(2) and getloginclass(2) syscalls, and modifying setusercontext(3) to pass that information to the kernel. The id(1) utility can be used to determine login class of a current process (id -c). Rule management is more or less done. I got rid of the rbtree that I used originally; rbtree was great for managing the rules, but it sucked for the most performance critical part - looking up the rules applicable to the process. Instead of the rbtree, the HRL rules are linked to the 'struct proc', 'struct uidinfo', 'struct gidinfo' or 'struct loginclass'. This makes listing or removing the rules slightly more complicated - we need to iterate over all these - but simplifies determining what rules apply to a given process. Locking needs to be reviewed, and there is one more TODO item that will simplify things a little further. Big missing part - or, actually, not missing but defunct - is a part of code that copes with changing uids and gids. This will get rewritten in the next few days. Code to account for resources used by a process is there, but it still needs to be debugged. Code to enforce resource rules should work as it is, except that it's not tested because of the previous point. Note that the per-CPU part, which is crucial to achieve acceptable performance, is not yet written. -- If you cut off my head, what would I say? Me and my head, or me and my body?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090803181334.GA46526>