Re: page fault scalability patch V11 [0/7]: overview

From: Nick Piggin
Date: Fri Nov 19 2004 - 23:15:11 EST


William Lee Irwin III wrote:
William Lee Irwin III wrote:

Irrelevant. Unshare cachelines with hot mm-global ones, and the
"problem" goes away.


On Sat, Nov 20, 2004 at 02:14:33PM +1100, Nick Piggin wrote:

That's the idea.



William Lee Irwin III wrote:

This stuff is going on and on about some purist "no atomic operations
anywhere" weirdness even though killing the last atomic operation
creates problems and doesn't improve performance.


On Sat, Nov 20, 2004 at 02:14:33PM +1100, Nick Piggin wrote:

Huh? How is not wanting to impact single threaded performance being
"purist weirdness"? Practical, I'd call it.


Empirically demonstrate the impact on single-threaded performance.


I can tell you its worse. I don't have to demonstrate anything, more
atomic RMW ops in the page fault path is going to have an impact.

I'm not saying we must not compromise *anywhere*, but it would
just be nice to try to avoid making the path heavier, that's all.
I'm not being purist when I say I'd first rather explore all other
options before adding atomics.

But nevermind arguing, it appears Linus' suggested method will
be fine and *does* mean we don't have to compromise.


On Sat, Nov 20, 2004 at 01:40:40PM +1100, Nick Piggin wrote:

Why the Hell would you bother giving each cpu a separate cacheline?
The odds of bouncing significantly merely amongst the counters are not
particularly high.


On Sat, Nov 20, 2004 at 02:14:33PM +1100, Nick Piggin wrote:

Hmm yeah I guess wouldn't put them all on different cachelines.
As you can see though, Christoph ran into a wall at 8 CPUs, so
having them densly packed still might not be enough.


Please be more specific about the result, and cite the Message-Id.


Start of this thread.
-
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/