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

[david]

On Tue, 7 Jun 2011, pageexec@xxxxxxxxxxx wrote:

> On 6 Jun 2011 at 18:47, Ingo Molnar wrote:
>
> > * pageexec@xxxxxxxxxxx <pageexec@xxxxxxxxxxx> wrote:
> >
> > > > > sorry, but stating that the pf handler is a fast path doesn't
> > > > > make it so ;).
> >
> > and 5-6 mails down the line you are still unwilling to admit it. Why?
>
> why are you cutting out in all those mails of yours what i already told
> you many times? the original statement from Andy was about the int cc path
> vs. the pf path: he said that the latter would not tolerate a few well
> predicted branches (if they were put there at all, that is) because the
> pf handler is such a critical fast path code. it is *not*. it can't be
> by almost definition given how much processing it has to do (it is by
> far one of the most complex of cpu exceptions to process).

it seems to me that such a complicated piece of code that is executed so 
frequently  is especially sensitive to anything that makes it take longer

> > A fastpath is defined by optimization considerations applied to a
> > codepath (the priority it gets compared to other codepaths), *not* by
> > its absolute performance.
>
> we're not talking about random arbitrarily defined paths here but the
> impact of putting well predicted branches into the pf handler vs. int xx
> (are you perhaps confused by 'fast path' vs. 'fastpath'?).

as someone watching, I know that I don't see what difference adding or 
removing a space makes.

the fast path or fastpath refers to the path that is the most performance 
critical (no matter how long the processing takes)

> that impact only matters if it's measurable. you have yet to show that it
> is. and all this sillyness is for a hypothetical situation since those
> conditional branches don't even need to be in the general page fault
> processing paths.

he has shown examples of other 'minor' changes in this code that have been 
considered very significant. given that so much processing already takes 
place here, there is unlikly to be extra processor cycles that can be used 
without making any impact.

> > You seem to be confused on several levels here.
>
> you're talking about something else, probably because it's you who's
> very confused about this whole fast path business. kinda surprising
> given how much time you supposedly spent on this topic in the past.

please educate the rest of us on what you think 'fast path' and 'fastpath' 
mean (and why you think they are so different)

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