Messages in this thread | | | Date | Sun, 31 Jan 1999 08:53:47 +1100 | From | Richard Gooch <> | Subject | Re: Page coloring HOWTO [ans] |
| |
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/
| |