Re: accessed/dirty bit handler tuning

[Zoltan Menyhart <Zoltan.Menyhart@bull.net>]

Chen, Kenneth W wrote:

> Oh my gosh, my worst nightmare becomes the reality, :-( It is unacceptable
> to have srlz.d in vhpt_miss.

Can you please explain why it is a nightmare?
How much time do you think will be wasted?

>  Couple of alternatives:
>
> (1) strip off all ptc.g related instructions in vhpt and just let the hpw
>     walker do the job.  Kernel can take double faults, but after all, with
>     what people do to ia64 kernel, this might be the best solution.

I do not really see why it would be more efficient to let the walker do
the inserting job, once we are in the "vhpt_miss" handler.

If we suffer from the delay, why could the walker avoid this overhead?

Have you got a prototype for this reduced "vhpt_miss" handler ?

> (2) add 20 cycles of delay in front of ptc.g

I do not think any delay like this could be safe.

> (3) dynamically patch out srlz.d for McK/Madison/Montecito processor.

Is it specified anywhere what CPU models do / do not require this "srlz.d"?

Thanks,

Zoltan