Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers
From: Andi Kleen (ak_at_suse.de)
Date: 09/17/03
- Previous message: Ranjeet Shetye: "[CVS] How do I get 'cvs history' to work for linux-2.5 ?"
- In reply to: Linus Torvalds: "Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers"
- Next in thread: Linus Torvalds: "Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers"
- Reply: Linus Torvalds: "Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 17 Sep 2003 22:21:00 +0200 To: Linus Torvalds <torvalds@osdl.org>
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Ranjeet Shetye: "[CVS] How do I get 'cvs history' to work for linux-2.5 ?"
- In reply to: Linus Torvalds: "Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers"
- Next in thread: Linus Torvalds: "Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers"
- Reply: Linus Torvalds: "Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
