From owner-soc-status@FreeBSD.ORG Wed Jun 23 12:50:16 2010 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65D52106566B; Wed, 23 Jun 2010 12:50:16 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8638FC15; Wed, 23 Jun 2010 12:50:15 +0000 (UTC) Received: by wyb33 with SMTP id 33so5208519wyb.13 for ; Wed, 23 Jun 2010 05:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l5PxfL7gjLhEygGAt0Zo7OHYpAAEjHzdA4WvHxZ0GbI=; b=ieAwbD7GIuEPYp8lIW5nIesLGAoC10RefrwfGjT/GZbN/ilwhHjAaUzdVG3+5ajZVL enDsYF2Jb8z96jg2HstnLsKN60ABMJYDvbV41LDm6MPSwOGBE8a/4pD654IzsFNDc+Q9 EmYWtDZX1Y4lUdbnSrmFst060O4p18wSGEhM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g0XNlsDk45MVOTfs0nH4LeMGk5GrAOJVAeCO0yadUu27CIoIIF/pWyrludKy/ZJ02z ghq0CCnBt3SLp/rcLCPDuJIdsWGPeexLG+5jOR9BdGbiXJ6jllqa4/nt5SPdkYfdKwYS BS+LnksvcUQSAazFmwTu4xtzBnaNNT9e+GE24= MIME-Version: 1.0 Received: by 10.227.152.204 with SMTP id h12mr7377957wbw.108.1277297095549; Wed, 23 Jun 2010 05:44:55 -0700 (PDT) Received: by 10.216.51.78 with HTTP; Wed, 23 Jun 2010 05:44:55 -0700 (PDT) In-Reply-To: <4C21CAF0.2040607@FreeBSD.org> References: <4C1BCB96.4040608@FreeBSD.org> <4C21CAF0.2040607@FreeBSD.org> Date: Wed, 23 Jun 2010 16:44:55 +0400 Message-ID: From: pluknet To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 12:50:16 -0000 On 23 June 2010 12:50, Gabor Kovesdan 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