On Fri, 2006-08-04 at 13:11 -0700, Chandra Seetharaman wrote:
> On Fri, 2006-08-04 at 13:00 -0700, Andrew Morton wrote:
> > On Fri, 04 Aug 2006 12:14:23 -0700
> > Chandra Seetharaman <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, 2006-08-04 at 00:20 -0700, Paul Menage wrote:
> > > > Hi,
> > > >
> > > > The fixed-sized buffer used by show_members() means that currently if
> > > > you have a fairly large number of processes in a class (~1000) then
nit: We've replaced "class" with "resource group". :)
> > > > attempts to read the "members" file for that class fail with ENOSPC.
> > > > What's the plan for getting round that problem?
> > > >
> > > > The cleanest approach that I can think of would be to extend configfs,
> > > > to allow configfs entries to (optionally) report values via a seq_file
> > > > interface rather a fixed-sized buffer.
> > >
> > > This is the plan. But, the configfs maintainer was not happy with that
> > > feature addition as it will make the file system more complex.
> >
> > In a contest between "complex" and "having some pathetic limitation", we'll
> > take "complex".
> >
> > Did the configfs maintainer (was it Mark?) have some other proposed fix?
>
> I think it was Joel. His point was that files in configfs was intended
> to be used as attr=value type of usage, and data worth of PAGE_SIZE is
> good enough for that kind of usage.
Another alternative might be to represent the tasks in the resource
group as multiple files -- families (similar names) or directories of
files.
Families would look like:
resource group/
members00 (the first 340 tasks)
members01 (tasks 341-780)
members02 ...
...
child resource group/
...
Directories of files would look like:
resource group/
members/
20560
20561
21040
...
...
child resource group/
...
We'd need to forbid the creation of resource groups with the prefix
'members' in the name.
In terms of avoiding limitations and offering fast access to the list of
tasks I think the Families approach works best. However the directory of
files may be more intuitive.
> >
> > If not, a seq_file-based fix sounds OK to me. We don't have to actually
> > merge it until something which needs it is also in-tree, but a 1000-item
>
> Yes :) Since ckrm/RG is not in-tree, i did not pursue it further.
>
> > limit (depends on PAGE_SIZE, too?) is silly.
I agree, however we made an effort to pare down the complexity of the
code introduced by the patches. We felt most reviewers would consider
changes to configfs to be unnecessary bloat/complexity.
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
