From owner-freebsd-chat@FreeBSD.ORG Sat Jan 17 16:42:57 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4804016A4CE for ; Sat, 17 Jan 2004 16:42:57 -0800 (PST) Received: from gldis.ca (constans.gldis.ca [66.11.169.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABFD243D55 for ; Sat, 17 Jan 2004 16:42:55 -0800 (PST) (envelope-from gldisater@gldis.ca) Received: from gldis.ca (localhost [127.0.0.1]) by gldis.ca (8.12.8p2/8.12.8) with ESMTP id i0I0eABc015492; Sat, 17 Jan 2004 19:40:11 -0500 (EST) (envelope-from gldisater@gldis.ca) Message-ID: <4009D71E.3020209@gldis.ca> Date: Sat, 17 Jan 2004 19:45:18 -0500 From: Jeremy Faulkner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <6.0.1.1.1.20040116175159.03f4dd48@imap.sfu.ca> <6.0.1.1.1.20040118000417.02bbee70@imap.sfu.ca> In-Reply-To: <6.0.1.1.1.20040118000417.02bbee70@imap.sfu.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on constans.gldis.ca cc: freebsd-chat@freebsd.org Subject: Re: Good BSD/Linux Article (somewhat off-topic) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 00:42:57 -0000 Colin Percival wrote: > At 23:59 17/01/2004, Robert Watson wrote: > >> I suspect that the /. effect has gotten easier to carry >> over time in part because a lot of the clients are higher bandwidth than >> they were before -- if you have moderate size files being tranfered, lots >> of long-lived slow connections take up a lot more memory than short-lived >> ones. > > > Actually, this raises an interesting point -- if > 1. There is a significant amount of network traffic, > 2. There is memory pressure, and > 3. There are several runnable processes, > it might be a good idea to give scheduling priority to the oldest > process, in the hope that it will complete and free its memory. > > Colin Percival dnetc and seti would be the oldest process on some machines. So making this a mandatory setting would be counter productive. -- Jeremy Faulkner http://www.gldis.ca