Re: page fault scalability patch V12: rss tasklist vs sloppy rss

[Christoph Lameter]

On Thu, 9 Dec 2004, William Lee Irwin III wrote:

> On Thu, Dec 09, 2004 at 03:07:13PM -0800, Christoph Lameter wrote:
> > Sloppy rss left the rss in the section of mm that contained the counters.
> > So that has a separate cacheline. The idea of putting the atomic ops in a
> > group was to only have one exclusive cacheline for mmap_sem and the rss.
> > Which could lead to more bouncing of a single cache line rather than
> > bouncing multiple cache lines less. But it seems to me that the problem
> > essentially remains the same if the rss counter is not split.
>
> The prior results Robin Holt cited were that the counter needed to be
> in a different cacheline from the ->mmap_sem and ->page_table_lock.
> We shouldn't need to evaluate splitting for the atomic RSS algorithm.

Ok. Then we would need rss and rss_anon on two additional cache lines?
Both rss and anon_rss on one line? mmap_sem and the page_table_lock also
each on different cache lines?

> A faithful implementation would just move the atomic counters away from
> the ->mmap_sem and ->page_table_lock (just shuffle some mm fields).
> Obviously a complete set of results won't be needed unless it's very
> surprisingly competitive with the stronger algorithms. Things should be
> fine just making sure that behaves similarly to the one with the shared
> cacheline with ->mmap_sem in the sense of having a curve of similar shape
> on smaller systems. The absolute difference probably doesn't matter,
> but there is something to prove, and the largest risk of not doing so
> is exaggerating the low-end performance benefits of stronger algorithms.

The advantage in the split rss solution is that it can be placed on the
same cacheline as other stuff from task that is already needed. So there
is minimal overhead involved. But I can certainly give it a spin and see
what the results are.

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