On Fri, Aug 04, 2006 at 04:17:10PM -0700, Chandra Seetharaman wrote:
> On Fri, 2006-08-04 at 14:36 -0700, Joel Becker wrote:
> > [Thanks for copying me on this]
>
> I am confused with the usage model description.
I'm just making up things trying to understand.
> > config/ckrm/things/
> > 1
> > 2
> > 3
>
> When is "things" created (at registration of subsystem or when user
> creates a directory) ?
> when are 1, 2, 3 created ?
I was considering "things" the potential members of a resource
group. I now see that you do this by pid, so you could say that
config/ckrm/things/1 really would map to config/ckrm/pids/1. You
probably don't have a config/ckrm/pids/<pid> object set (why make an
object per pid :-), you are adding raw pid numbers to your resource
group file. So this "things" directory wouldn't exist. Sorry for the
confusion.
> > and a list of groups:
> >
> > config/ckrm/groups/
> > family1
> > family2
>
> Are family1 and family2 "items" or attributes ?
> How is family1 and family2 created ?
I was hearing the text of the email say 'family' for groups, and
so I was just playing fast and loose with example names. 'family1'
would be a resource group name.
> > then configfs' symlink is a great way to join them:
> >
> > ln -s config/ckrm/things config/ckrm/groups/family1
>
> I am not able to come out file my basic filesystem usage to understand
> this. I 'll look at configfs docs to understand this clearer.
Since you don't have a configfs object for each pid, you can't
use symlink(2) here. My bad.
> Here is how RG/CKRM uses configfs:
>
> - A Resource group is a group of tasks that uses specified amount of
> resources.
> - A Resource group is represented by a directory in configfs filesystem.
> - Each directory has few attributes
> - shares, list the amount of resource that group is allowed (rw)
> - stats, usage statistics of the group (ro)
> - members, list of tasks that are member of this group (rw)
You could use 'mkdir' under members to create an object for each
member:
# mkdir config/ckrm/groups/thisresourcegroup/members/2209
but I don't know how heavy or light that would be for you. I think
someone in the previous mail chain thought this wasn't optimal.
> The problem we have with is the members file, whose content could exceed
> PAGE_SIZE when more than ~1000 tasks are in a group.
Right, this I do understand.
> We choose configfs instead of sysfs after following the guidance in the
> doc.
>
> Basically we wanted a "file-system based manager of kernel object"
> rather than a "file-system based view of a kernel object".
Yes, I think configfs fits your intent well. I want to work
together to see what we can do.
> I think we could implement in sysfs also. But, doesn't sysfs also have
> the PAGE_SIZE limitation.
They do for standard attributes. That's where my limit comes
from...I cut and pasted the code. However, sysfs also allows you to
arbitrarily add objects to the filesystem tree, so you can place a
seq_file or other object in the directory. The problem is that this
object has an uncontrolled set of lifetime semantics. This has led to
issues in the past. It's something I'm trying to avoid with configfs.
Joel
--
"The whole problem with the world is that fools and fanatics are always
so certain of themselves, and wiser people so full of doubts."
- Bertrand Russell
Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
-------------------------------------------------------------------------
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
