Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers

[Andi Kleen]

On Wed, Sep 17, 2003 at 12:53:59PM -0700, Linus Torvalds wrote:
> 
> On Wed, 17 Sep 2003, Nick Piggin wrote:
> > 
> > What is intriguing to me is the "Its only a 2% slowdown of the page
> > fault for every cpu other than K[78] for this single workaround. There
> > is no point to conditional compilation" attitude some people have.
> 
> I wouldn't worry about performance as much as correctness. I'm a lot more
> worried about the notion of taking recursive pagefaults than about 2%.

I carefully designed it to never recurse more than once. The original
version (before I posted it) had some corner cases that violated this, but 
the latest one is IMHO bulletproof in this regard.

Logic is: 

when the fault came from user space as seen in CS it is ok to fault again. 

when the fault came from kernel space we must always check the exception
table first. The __get_user is is_prefetch has an exception table entry
and will be catched by this.
[This is why I changed the SIGBUS path slightly - it previously did 
not follow this sequence]

Also when the fault address is equal EIP we don't check. This avoids
a recursion when the kernel jumps to zero. When this is not true the
instruction is guaranteed to be mapped, because an unmapped instruction
will always cause an page fault on EIP first.

About the only chance of doing multiple recursions would be another CPU
corrupting the kernel page table in parallel while the fault happens, 
but I don't see any chance to handle this properly.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/