On Tue, Aug 31, 2004 at 11:06:47AM +0200, Guillaume Thouvenin wrote:
> On Fri, Aug 27, 2004 at 12:55:03PM -0700, Jay Lan wrote:
> > Please visit http://oss.sgi.com/projects/pagg/
> > The page has been updated to provide information on a per job
> > accounting project called 'job' based on PAGG.
> >
> > There is one userspace rpm and one kernel module for job.
> > This may provide what you are looking for. It is a mature product
> > as well. I am sure Limin(job) and Erik(pagg) would appreciate any
> > input you can provide to make 'job' more useful.
>
> I have a question about job. If I understand how it works, you can not
> add a process in a job. I mean when you start a session, a container is
> created and it's the only way to create it.
Right, that's the current implementation. Any privileged process can
create a job, though, it doesn't *have* to be at the start of a session.
I believe job is currently hardwired that the initial member process is
the creator, and the only other way in is via inheritance, and there's
no way out of the job other than exiting or creating your own job.
> If I'm right, I think that it could be interesting to add a process
> using ioctl and /proc interface.
We're planning on changing that interface, but I think your question
applies regardless of what interface is used.
> For example, if I want to know how resources are used by a
> compilation, I need to add the process gcc in a container. Any
> comments?
>
> Best,
> Guillaume
It sounds like a slightly different kind of job.
The gcc process should already be in a job via it's parent.
If it's already in a job, we don't let it out, as jobs are designed to
be inescapable so that users can't sneak processes outside their job.
If the only client of job is accounting, that might not be required.
Maybe as long as they become a member of another job, and the usage is
tracked, that would be OK. I'm not sure what that would do to
the current CSA tools, though.
On IRIX, I think jobs are also used to do resource limits, and that's
probably where the hard requirement for jobs being inescapable came from.
The ISP/ASP non-acct uses of job would probably want it to be inescapable.
Different inheritance and creation policies could be implemented
in job. Or, since it's just a loadable module, different job modules
could be written to implement different styles of job as are required
for different uses.
John