From owner-cvs-src@FreeBSD.ORG Mon Aug 8 16:57:13 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 291DF16A41F; Mon, 8 Aug 2005 16:57:13 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A268A43D45; Mon, 8 Aug 2005 16:57:11 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.3/8.13.3) with ESMTP id j78GvAgB022151; Mon, 8 Aug 2005 17:57:10 +0100 (BST) (envelope-from dfr@nlsystems.com) In-Reply-To: <749ADAD2-6AF5-4412-A880-22812A2C634C@xcllnt.net> References: <200508062028.j76KSJtM019032@repoman.freebsd.org> <200508070941.33821.dfr@nlsystems.com> <200508080911.32706.dfr@nlsystems.com> <749ADAD2-6AF5-4412-A880-22812A2C634C@xcllnt.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14FBC006-01EA-4864-8D90-4D498EB63238@nlsystems.com> Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Mon, 8 Aug 2005 17:57:11 +0100 To: Marcel Moolenaar X-Mailer: Apple Mail (2.733) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.qubesoft.com X-Virus-Scanned: ClamAV 0.86.1/1008/Sun Aug 7 23:59:27 2005 on mail.qubesoft.com 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2005 16:57:13 -0000 On 8 Aug 2005, at 17:49, Marcel Moolenaar wrote: > On Aug 8, 2005, at 1:11 AM, Doug Rabson wrote: > > >>> 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). >> > > I made them spin mutexes already. For the reasons you mentioned. I'll > play with it a bit. Obviously, the hard bit is making sure that you don't deadlock by taking a TLB fault while holding the mutex. It ought to be possible to do this by explicitly doing any necessary VA->PA conversions outside the mutex. I would be worried that the compiler would try to break things by doing unexpected stack accesses. > > >>> 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 larger VHPT does not necessarily improve performance. I think I got > the best results with a 64K VHPT in a 2GB machine. The performance > deltas were really small, but that might be due to the particulars of > the load I put onto the machine. The effects on large databases may > be better for example. > > >> 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. >> > > I think the algorithm is defined in the architecture specification. It > should be possible to analyze it and determine if get a good > distribution. > > We probably get better results if we share translations across > processes. > For this to work, we need to use the permission keys so that we can > assign > different permissions per process without having to create new > translations > for it. Right.