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 - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|