Date: Sun, 7 Aug 2005 11:50:49 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> 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: <FAABF8ED-0FC7-4FBB-98D2-3A9F2618480F@xcllnt.net> In-Reply-To: <200508070941.33821.dfr@nlsystems.com> References: <200508062028.j76KSJtM019032@repoman.freebsd.org> <200508070941.33821.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAABF8ED-0FC7-4FBB-98D2-3A9F2618480F>