* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-02-21 01:19]: > > >> I would really rather not see the setrlimit(2) emulation in the > >> resource control framework extended. > > > >Why ? > > Setrlimit() suffers from a few restrictions: > > - it's per process > - it can only do a soft and hard limit. > > Per process limits have a drawback in that the actual limit is: > > - maxprocs * limit > > similarly, I have some issues with "tasks" (same issue as > processes) and projects (in order to have per-user resource limits > each user need to be assigned its own project and set of resources) > > Looking from what the angle of what I as administrator would want to > do is: > > - keep total resource consumption of a zone in check > (so the zone.* rctls are good) > > - defined an upperbound for all users individually > (I can't easily do that at the moment, I think) > > as a user, I would be most interested in > > - preventing huge core dumps > - preventing runaways > > for this the task and process limits seem adequate. > > But as an administrator, I really would like to have "user.anything" > type of rctls.
The way we were hoping to do this was to have "wildcard" projects, so that each user would have a project synthesized automatically upon login. Then all the project controls (and the cascaded task controls) apply per-user. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
