From owner-cvs-all@FreeBSD.ORG Mon Aug 8 08:11:48 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D96216A41F; Mon, 8 Aug 2005 08:11:48 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BFA43D46; Mon, 8 Aug 2005 08:11:46 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id j788BXEp002844; Mon, 8 Aug 2005 09:11:38 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Marcel Moolenaar Date: Mon, 8 Aug 2005 09:11:31 +0100 User-Agent: KMail/1.8 References: <200508062028.j76KSJtM019032@repoman.freebsd.org> <200508070941.33821.dfr@nlsystems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508080911.32706.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Mon, 08 Aug 2005 09:11:38 +0100 (BST) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1008/Sun Aug 7 23:59:27 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: cvs-src@FreeBSD.org, Marcel Moolenaar , cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/ia64 exception.S interrupt.c machdep.c mp_machdep.c pmap.c trap.c vm_machdep.c src/sys/ia64/include proc.h smp.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2005 08:11:48 -0000 On Sunday 07 August 2005 19:50, Marcel Moolenaar wrote: > On Aug 7, 2005, at 1:41 AM, Doug Rabson wrote: > > Excellent! When trying to think about per-cpu VHPT in the past, I > > could > > never quite see how to handle the collision chains sanely. The > > solution > > described below seems ideal. > > I'm quite happy with it as well. The hash bucket head structure > allows for > the collection of per-bucket statistics. I already have a length > field that holds the length of the chain (or number of PTEs in the > bucket). What > I'd like to do is get a better sense of how critical it is if there's > a VHPT miss. Maybe we can implement the code that handles it in C, > use locks > and open the doors to having various different hash bucket > implementations > to play with. I still have my concerns about the assembly in > exception.S and the lack of locking therein. This in the context of > having spurious core dumps. If you make it a spin mutex, I think it might be possible to take the mutex from exception.s safely. The uses of this mutex should be extremely short (and collisions rare). > > In parallel, I'm measuring the effect on performance of bumping up > the page > size to 16K and 32K. I suspect the cost of a VHPT miss is mostly due > to us > needing to find the PTE in the hash bucket by walking a linked list. > Keeping > the average length of the list small may improve our overall > performance. > > Lots to learn... How about the effect of different VHPT sizes? A long time ago I experimented with different ways of assigning region IDs to processes in an attempt to reduce collisions (and therefore reduce collision chain length). I think there still might be some mileage in that direction.