Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

[pageexec]

On 6 Jun 2011 at 17:26, Ingo Molnar wrote:

> 
> * pageexec@xxxxxxxxxxx <pageexec@xxxxxxxxxxx> wrote:
> 
> > > > a page fault is never a fast path, after all the cpu has just 
> > > > taken an exception (vs. the syscall/sysenter style actually 
> > > > fast user->kernel transition) and is about to make page table 
> > > > changes (and possibly TLB flushes).
> > >
> > > Sure it is.  It's a path that's optimized carefully and needs to 
> > > be as fast as possible.  Just because it's annoyingly slow 
> > > doesn't mean we get to make it even slower.
> > 
> > sorry, but stating that the pf handler is a fast path doesn't make 
> > it so ;) [...]
> 
> Are you talking about the Linux kernel?

yes, what else? ;)

> FYI, incredible amount of work has gone into making pagefaults as 
> fast and scalable as possible.

i wasn't talking about scalability (it's irrelevant anyway here), only
speed. you're the man with the (in)famous measuring stick, tell me how
many cycles it takes to serve a C-O-W fault or instantiation of an anon
page and a file page (both cached and non-cached). then stick a few well
predicted conditional branches in that path (something that wouldn't
actually happen with my code but let's play this out fully) and show me
measured differences. then we'll talk about the 'impact on fast path'.

> If you are following Linux kernel development you'd have to be
> virtually blind to not see all that effort. 

nice attempt to question me but it won't get you anywhere (didn't i just
tell you to heed your own advice?). case in point, i'd fixed the anon_vma
refcount leak (exploitable and silently fixed as usual in mainline) a
few months before you guys did. just by reading the code. now show me
that you know your stuff around and can find the commit i'm talking about.
unless of course you are not "following Linux kernel development" and
are "virtually blind to not see all that effort".
 
> You claiming that pagefaults are a slow-path and ridiculing those who 
> point out your mistake does not make it a slowpath.

you must have realized by now that slow/fast path in this context were
relative to int xx vs. pf processing. and i'm yet to receive the numbers
that show how much faster the latter is processed than the former and why
sticking a few well predictable conditional jumps (no really, they would
not be there, but let's assume they are) shows a measurable impact on
these all so fast pf paths.

--
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/