From owner-p4-projects@FreeBSD.ORG Mon Aug 21 09:47:50 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 670C916A4E0; Mon, 21 Aug 2006 09:47:50 +0000 (UTC) X-Original-To: perforce@FreeBSD.org Delivered-To: perforce@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12B7A16A4DA for ; Mon, 21 Aug 2006 09:47:50 +0000 (UTC) (envelope-from cdjones@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9EE43D55 for ; Mon, 21 Aug 2006 09:47:46 +0000 (GMT) (envelope-from cdjones@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id k7L9lkxq064865 for ; Mon, 21 Aug 2006 09:47:46 GMT (envelope-from cdjones@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id k7L9lkeC064862 for perforce@freebsd.org; Mon, 21 Aug 2006 09:47:46 GMT (envelope-from cdjones@FreeBSD.org) Date: Mon, 21 Aug 2006 09:47:46 GMT Message-Id: <200608210947.k7L9lkeC064862@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to cdjones@FreeBSD.org using -f From: Chris Jones To: Perforce Change Reviews Cc: Subject: PERFORCE change 104669 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 09:47:50 -0000 http://perforce.freebsd.org/chv.cgi?CH=104669 Change 104669 by cdjones@cdjones_meanook on 2006/08/21 09:47:06 More info on how to use etc. Affected files ... .. //depot/projects/soc2006/cdjones_jail/docs/STATUS#2 edit Differences ... ==== //depot/projects/soc2006/cdjones_jail/docs/STATUS#2 (text+ko) ==== @@ -1,35 +1,40 @@ Memory Limits ============= -Jails can now have the amount of memory available to their processes' -resident sets (RSS) with arguments to the jail command (and shortly, the -jtune command once a jail is running). A kernel thread for each jail, -jpager_td, periodically traverses the processes in the jail and sums the -amount of memory being consumed by the jail; if that exceeds the pre-set -limit, jpager_td asks the virtual memory system to reclaim some of the -memory being used by the jail's processes. +Jails can now have the amount of memory available to their processes' +resident sets (RSS) with arguments to the jail command and the jtune +command. + +A kernel thread for each jail, jpager_td, periodically traverses the +processes in the jail and sums the amount of memory being consumed by +the jail; if the security.jail.limit_jail_memory sysctl is set and the +jail's memory exceeds the pre-set limit, jpager_td asks the virtual +memory system to reclaim some of the memory being used by the jail's +processes. -Currently, memory reclamation is based on a fraction of the process's -RSS and is applied to all of the processes in the jail (e.g. both a 30MB -Apache process and a 300KB shell might be asked to return 1/16 of their -RSS). This allows for short-term overcommits which return to the -established limit over time; a sysctl will allow tuning of how quickly -that return happens. +Currently, all processes in the jail are asked for 6.25% (1/16th) of +their resident set size. This means that both a 30MB Apache process and +a 300KB shell will be asked to return 1/16 of their RSS). This allows +for short-term overcommits which return to the established limit over +time; the security.jail.jail_pager_timeout sysctl determines how +frequently (in seconds) the pager thread checks memory usage. -Things to think about: progressive taxation of processes (e.g. charging -the 30MB Apache process a higher rate). +Things to think about for the future: progressive taxation of processes +(e.g. charging the 30MB Apache process a higher rate). CPU Limits ========== -CPU limiting is implemented by giving each jail a (user-changeable) -number of CPU shares and tracking the estimated CPU usage of the tasks -that run in that jail. If the ratio of the jail's estimated CPU usage to -total CPU usage exceeds the ratio of the jail's CPU shares to total CPU -shares outstanding, the jailed processes have their priorities decreased -until the ratio of actual usage (estimated CPU) drops below permitted -usage (shares). Unjailed processes are not subject to this regime. +CPU limiting is implemented by giving each jail a number of CPU shares +and tracking the estimated CPU usage of the tasks that run in that jail. +If the ratio of the jail's estimated CPU usage to total CPU usage +exceeds the ratio of the jail's CPU usage shares to total CPU usage +shares outstanding, the jailed processes have their priorities decreased +until the ratio of actual usage (estimated CPU) drops below permitted +usage (shares). In short, the more shares a jail has, the more often +its processes will run. Unjailed processes are not subject to this +regime. This system does not prevent a jailed process from monopolizing the CPU when there are no other runnable processes; rather, it only prevents a @@ -37,6 +42,13 @@ processes (in which case they will tend to share CPU time in proportion to their respective CPU share allocations). +The kern.sched.limit_jail_cpu sysctl enables jail CPU usage limits, and +the kern.sched.system_cpu_shares sysctl determines how many CPU usage +shares are attributed to unjailed processes. While they count towards +the total number of CPU usage shares outstanding on a system (and so +decrease the priority of jails), they do not affect the priority of +unjailed processes. + Future work could look at implementing a full-blown fair-share scheduler (see Kay & Lauder or Waldspurger).