On Fri, 2006-08-04 at 15:05 -0700, Dave Hansen wrote:
> On Fri, 2006-08-04 at 15:01 -0700, Paul Menage wrote:
> > So is there an argument against moving to reporting things like
> > membership (and maybe arbitrary stats) via sysfs rather than configfs?
>
> Is there a reason to do it, other than keeping configfs simple?
>
> Seems fine to me, otherwise. Frankly, if we're talking about _process_
> grouping, does it make some sense to put these things in /proc?
>
> -- Dave
I think we're already reporting what class a task is in
via /proc/<pid>/resource_group (I may be misremembering the exact file
name..).
The members file has two functions. The first and most important
function is assigning a task to a resource group (append). The second
function is a quick consistent way to determine membership of a given
group (read).
We could use only the /proc/<pid>/resource_group file. When we wish to
move a task from one group to another we simply rewrite
its /proc/<pid>/resource_group file to "point" to the new resource group
in configfs. Then, assuming group membership is stable, we could
accumulate the same information with much more work by parsing
every /proc/<pid>/resource_group file. I think we chose not to do this
because we expected the locking to be *much* more complex (have to make
sure the classes in the rcfs path don't go away in the middle of
assignment).
The current interface is nice (though limited) becase using the read
semantics to display the list of members is consistent with the file
write semantics used to assign the task to the group.
Cheers,
-Matt Helsley
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
