Messages in this thread | | | Date | Wed, 1 Sep 2004 16:44:43 -0500 | From | John Hesterberg <> | Subject | Re: [Lse-tech] Re: [PATCH] new CSA patchset for 2.6.8 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |