Devlimit / Rlimit is less than ideal - the resource limits aren't adaptive to program needs and to resource availability. They would be describing resources that user programs have very little visible control over (kernel resources), except by changing their syscall mix or giving up a segment or so. Or failing outright.
Prohibitions per-user are kinda bad in general - what if you want to run a potentially hostile (or more likely buggy) program? You can already run it in its own ns, but having it be able to stab you via kernel resources, about which you can do nothing, is bad. The typed allocator is worth looking at for speed reasons - the slab allocator and customalloc have shown that its faster (from the perspective of allocation time, fragmentation) to do things that way. But I don't really see it addressing the problem? Now the constraints are per-resource, but they're still magic constraints. Something that might be interesting would be for each primitive pgroup to be born with a maximum percentage 'under pressure' associated with each interesting resource. Child pgroups would allocate out of their parent's pgroup limits. Until there is pressure, limits could be unenforced, leading to higher utilization than magic constants in rlimit. To give a chance for a process to give up some of its resources (caches, recomputable data) under pressure, there could be a per-process /dev/halp device, which a program could read; reads would block until a process was over its limit and something else needed some more soup. If the app responds, great. Otherwise, something like culling it or swapping it out (assuming that swap still worked :)) or even slowing down its allocation rate artificially might be answers... If people are interested, there is some work going on in a research kernel called Viengoos (http://www.gnu.org/software/hurd/microkernel/viengoos.html) (gasp! the hurd!) trying to address pretty much the same problem... -- vs
