From owner-freebsd-arch@FreeBSD.ORG Tue Mar 15 02:38:52 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF05516A4CE for ; Tue, 15 Mar 2005 02:38:52 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4837E43D46 for ; Tue, 15 Mar 2005 02:38:52 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2F2cpd4078131 for ; Mon, 14 Mar 2005 21:38:51 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2F2coLw078104 for ; Mon, 14 Mar 2005 21:38:51 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Mon, 14 Mar 2005 21:38:49 -0500 (EST) From: Jeff Roberson To: arch@freebsd.org Message-ID: <20050314213038.V20708@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Freeing vnodes. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2005 02:38:52 -0000 I have a patch at http://www.chesapeake.net/~jroberson/freevnodes.diff that allows us to start reclaiming vnodes from the free list and release their memory. It also changes the semantics of wantfreevnodes, and makes getnewvnode() much prettier. The changes attempt to keep some number of vnodes, currently 2.5% of desiredvnodes, that are free in memory. Free vnodes are vnodes which have no references or pages in memory. For example, if an application simply stat's a vnode, it will end up on the free list at the end of the operation. The algorithm that is currently in place will immediately recycle these vnodes once there is enough pressure, which will cause us to do a full lookup and reread the inode, etc. as soon as it is stat'd again. This also removes the recycling from the getnewvnode() path. Instead, it is done by a new helper function that is called from vnlru_proc(). This function just frees vnodes from the head of the list until we reach our wantfreevnodes target. I haven't perf tested this yet, but I have a box that is doing a buildworld with a fairly constant freevnodes count which shows that vnodes are actually being uma_zfree'd. Comments? Anyone willing to do some perf tests for me? Thanks, Jeff