From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 9 04:23:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5520C16A4DA for ; Wed, 9 Aug 2006 04:23:00 +0000 (UTC) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from correo.novusordo.net (cdjj.org [216.194.85.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 013FE43D46 for ; Wed, 9 Aug 2006 04:22:57 +0000 (GMT) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from [192.168.2.100] (S010600c049bda6b5.ed.shawcable.net [68.149.198.157]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by correo.novusordo.net (Postfix) with ESMTP id 6FEE311523; Tue, 8 Aug 2006 22:22:56 -0600 (MDT) In-Reply-To: <1154876916.5303.7.camel@berloga.shadowland> References: <1154876916.5303.7.camel@berloga.shadowland> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05B49B1A-C425-41BC-8676-AE6AEE29DF09@novusordo.net> Content-Transfer-Encoding: 7bit From: Chris Jones Date: Tue, 8 Aug 2006 22:22:18 -0600 To: Alex Lyashkov X-Mailer: Apple Mail (2.752.2) Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Jail Memory Limits X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2006 04:23:00 -0000 On 6-Aug-06, at 9:08 AM, Alex Lyashkov wrote: > I read you patch and see you start N kernel threads for control > memory/CPU usage, when each thread in loop count total memory usage. > What are reason why not create memory limit similar limit(1)? > for this need add pointer to prison structure at each VMA struct > and add > few checks at same points when LIMIT_VMEM and LIMIT_RSS checks. Hi, Alex --- there are a few reasons I chose not to do it that way: First, I think it makes more sense to limit memory over the jail as a whole, rather than against whichever process happens to hit the limit first; that suggests that the approach taken by limit(1) is probably not appropriate for my purposes. I could use that as a trigger to launch the "push things out of physical memory" bit, but it seems a bit unnatural to me. (I'm open to persuasion, though.) Second, I think that it's valuable to be able to overcommit memory to some extent; that is, turning this into a soft-ish limit rather than a hard limit. Being able to tune the response time, if you will, of enforcing the limit against a jail means that you could permit one jail to have a more lenient overcommit policy than another. Third, there's precedent for this in other OSes: Solaris implements its resource limits for zones (analogous to jails) in a similar manner. My apologies for not replying to this sooner; I've just got home from a few days' vacation in California, and to have worked on the project (I'm told including correspondence) while there would have not only been illegal for me but (worse!) created some major tax headaches. I look forward to your thoughts. Cheers, Chris