Re: Page coloring HOWTO [ans]

Richard Gooch (rgooch@atnf.csiro.au)
Sun, 31 Jan 1999 08:53:47 +1100


Larry McVoy writes:
> [ lots of stuff on how to do page coloring deleted ]
>
> I've seen how this was done twice, both at Sun and SGI. Here's what they
> do. This assumes a direct mapped level 2 cache, which is typical. It's
> different if it is set associative, how it is different is an exercise
> left for the reader.
>
> This alg will do two critical things:
>
> (a) make sure that each process maps the same virtual addresses to
> different locations in the cache, if possible.

What is the reasoning behind this? What are the benefits of just
having a global goal colour counter? As long as two processes, each
allocating a page, receive a different colour for their pages, then
they should be able to inhabit the cache at the same time.
Why take it further and the same virtual address should give different
colour pages?

> (b) make sure that a contiguous chunk of virtual address space in
> one process occupies a contiguous chunk of cache, if possible.

Again, why? Isn't it good enough that a contiguous chunk of virtual
address space maps to unique cache lines?

> Page allocation becomes hash on virtual address and take a page from
> the bucket.However, here's the trick that fans them out in the
> cache, you hash on virtual address plus pid (I don't remember the
> exact details but you'll get it immeditately when you implement it -
> you just process 0 to take page 0 from bucket 0, process 1 to take
> page 0 from bucket 1, and so on).

Can I assume from this scheme that, when reading blocks from disc, the
pid of the initiating process is used for the hash? Or is this
algorithm only used for anonymous pages?

> The nice thing about this model, by the way, is that it makes the
> system much more deterministic in its performance. Some programs
> will go faster, some will go slower, but the nice thing is that
> unlike the current situation, you can figure out which programs go
> slower and shuffle their data around to make them go faster. Under
> the current model, you're screwed because you get different results
> each time you run and there isn't a damn thing you can do about it.

Agreed. It's very hard to work out why your programme isn't performing
as expected when the OS doesn't provide a stable foundation.

> The point is that we should *not* use the fact that some programs go
> slower to mean that page coloring is bad. Fix the programs.

I assume you mean those programmes which are slowed down by page
colouring have a silly access pattern which results in cache line
aliasing? They only ran faster without page colouring because random
physical page allocations actually gave them a chance of avoiding this
aliasing?

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/