lkml.org 
[lkml]   [1998]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: "per-process" limits (was: Showstopper list)
Date
From
>Alan Cox writes:
>I actually wrote a few pieces of a thing called "beancounter" which was
>an idea to do this. I've not had time to do more than post the first
>draft version of the code ....

Well, I would have posted my stuff for task groups last week, but I
sense that there is 2.2 mania in the air, and that this is not the
time for something that is clearly a 2.3 item (all the more so since
task groups support loadable per-task-group scheduling).

>The code I had was less restrictive than the SCO idea - you have an luid
>which sets your current->beancounter. That is the beancounter to which all
>your resources get charged. Each resource object you allocate also makes
>a copy by reference counting of the bean counter so that it can free up
>the resources on an object.

This seems nice and simple, but not very generic in the sense that
there are properties shared by groups of tasks that aren't just
counters (e.g. when the group was last scheduled).

Also, in the current task group model I've implemented, threads can
belong to multiple distinct groups that are independent of user ID
(luid, guid, euid, uid, or any other variant). The group that a thread
might be in for the purpose of limiting network bandwidth might be
different than the one its in for the purposes of scheduling. Thus, so
far I have just one additional task member: current->sched_group, but
I imagine more (current->mem_group, current->net_group, etc.)

Also, someone else wrote about using ACL's. Although I think that
user-level limits are a great thing, I don't think that user ID should
be the starting point for implementing a limit system. Instead, you
create a mechanism for assigning a task to a group, plus a mechanism
for limiting the resource consumption of that group. Once this is
done, the user ID based stuff can be layered on top, but in a way that
leaves room for a per-process model at the same time.

--p


--p

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.089 / U:1.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site