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

[Doug Rabson]

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.