Date: Mon, 8 Aug 2005 09:11:31 +0100 From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-src@FreeBSD.org, Marcel Moolenaar <marcel@FreeBSD.org>, 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 Message-ID: <200508080911.32706.dfr@nlsystems.com> In-Reply-To: <FAABF8ED-0FC7-4FBB-98D2-3A9F2618480F@xcllnt.net> References: <200508062028.j76KSJtM019032@repoman.freebsd.org> <200508070941.33821.dfr@nlsystems.com> <FAABF8ED-0FC7-4FBB-98D2-3A9F2618480F@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508080911.32706.dfr>