Date: Wed, 23 Jun 2010 16:44:55 +0400 From: pluknet <pluknet@gmail.com> To: Gabor Kovesdan <gabor@freebsd.org> Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 Message-ID: <AANLkTikLoskpABjaUlufnBGOBeU-Z62CiuQfH5sDyY1Z@mail.gmail.com> In-Reply-To: <4C21CAF0.2040607@FreeBSD.org> References: <4C1BCB96.4040608@FreeBSD.org> <AANLkTikwUYWCIvlDQ60L4L8gMcEeDFIV6850csEwuH8E@mail.gmail.com> <4C21CAF0.2040607@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 June 2010 12:50, Gabor Kovesdan <gabor@freebsd.org> wrote:
> While trying to eliminate some bugs, I've looked at your patch in detail.
> I've adapted most part but I've got some comments.
>>
>> +typedef __uint32_t =A0 =A0 __jid_t;
>>
>
> This has to be signed because calls may return -1.
It might return jid_t (-1) then as it's done similarly for getpid(2) family
which return pid_t(-1) on error, or similarly for inet_addr(3) which return=
s
INADDR_NONE (0xffffffff, or -1 for uint32_t, let it be signed) on error.
>>
>> +#define =A0 =A0 =A0 =A0JLIM_NLIMITS =A0 =A08
>> +
>> +/*
>> + * Job limit string identifiers
>> + */
>> +
>> +#ifdef _JLIMIT_IDENT
>> +static char *jlimit_ident[JLIM_NLIMITS] =3D {
>> + =A0 =A0 =A0 "cputime",
>> + =A0 =A0 =A0 "datasize",
>> + =A0 =A0 =A0 "files",
>> + =A0 =A0 =A0 "processes",
>> + =A0 =A0 =A0 "threads",
>> + =A0 =A0 =A0 "vmemory",
>> + =A0 =A0 =A0 "physmem",
>> + =A0 =A0 =A0 "ressetsize",
>> +};
>> +#endif
>>
This is modeled by me after IRIX'ish jstat(1) manpage.
I'm still unsure, so it's up to you if it worth to be there.
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=3Dgetdoc&coll=3D=
0650&db=3Dman&fname=3D1%20jstat
(though I'm afraid it may be a bit obsolete).
> A quick look at the limit manipulation syscalls doesn't suggest that we n=
eed
> these. I see you did it in a consistent way with rlimits but why to have
> those if they aren't really necessary. Or are they?
>>
>> @@ -97,6 +102,8 @@
>> =A0 =A0 =A0 =A0 long =A0 =A0ui_ptscnt; =A0 =A0 =A0 =A0 =A0 =A0 =A0/* (b)=
number of pseudo-terminals
>> */
>> =A0 =A0 =A0 =A0 uid_t =A0 ui_uid; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* (a)=
uid */
>> =A0 =A0 =A0 =A0 u_int =A0 ui_ref; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* (b)=
reference count */
>> + =A0 =A0 =A0 jid_t =A0 ui_jid; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* (c) j=
ob in which this uid_t
>> lives */
>> + =A0 =A0 =A0 struct ulimit *ui_limit;
>> =A0};
>>
>
> Unfortunately, IRIX is not the most well-documented operating system, so =
I
> still have some doubts on the actual behavior but I don't think a user li=
ves
> in a job or does it? It's true that makenewjob() takes an uid_t argument =
but
> I think that will be a credential info for the created job, however I
> haven't been able to figure yet where it is used. What I am quite sure ab=
out
> is that job is an unescapable container and you can create a job with
> makenewjob(), which doesn't only create the job but associates the caller
> process to the job and then forked processes will also live in the same j=
ob.
> Please correct me if I am wrong. I've asked in the list if someone could
> provide me access to an IRIX machine but no answer yet...
I'd say some part (none, some processes, or all of them) of that (and only
that) user lives in a job.
Yeah, IRIX documentation has a bit of uncertainty for me as well.
They wrote: "With the IRIX kernel job limits feature, all processes
associated with a particular login session or batch submission are
encapsulated as a single logical unit called a job. The job is the
container used to group processes by login session."
But next: "Limits on resource usage are applied on a per user basis for a
particular job".
"Job limits software helps ensure that each user has access to the
appropriate amount of system resources such as CPU time and memory
and makes sure that users do not exceed their allotted amount."
Btw, it's interesting how to properly make getjusage(2), if a process
running inside a job wants to change it's uid/gid
(if basing on the claim that a job scope is limited by per-user basis).
> It would be nice to try out how it actually works on IRIX.
Yes, that would answer many questions...
--=20
wbr,
pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikLoskpABjaUlufnBGOBeU-Z62CiuQfH5sDyY1Z>