forgive me for asking what is probably a stupid question, but I was under
the impression that the cache management was a hardware/chipset issue, not
a user/kernel process or are you talking about reprogramming the hardware?
David Lang
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
On Sun, 31 Jan 1999, Larry McVoy wrote:
> Date: Sun, 31 Jan 1999 11:12:02 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: page coloruing tutorial questions [Re: Page coloring HOWTO
[ans]]
>
> : > 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
> :
> : What does it mean "cache line aliasing"?
>
> I'm not sure that is the correct terminology, but what we were talking
> it is this: If you have P physical pages and a cache size of C pages,
> and the cache is direct mapped, then you can potentially have P /
> C pages trying to be in the cache at the same time.
>
> : And what does it mean that a page is coloured or not?
>
> Page coloring is just a weird way of saying pageno % C. Suppose I had
> a very small cache, 8KB with 4KB pages. Then I would have two "colors",
> call 'em black and white. The black pages are those pages that satisfy
> pageno % 2 == 0; the white pages are pageno % 2 == 1.
>
> For wahtever reason, when people were dreaming this stuff up, it was
> too complicated to say pageno % cachesize. But that's all a color is.
>
> : What is the point of page colouring? Do you want to avoid TLB misses or is
> : only a L1/L2 cache issue? (or both?)
>
> All you are doing is trying to evenly spread out the process' pages
> through the L2 cache - L1 caches are typically set associate so they
> don't have this problem, or have it to a much lesser extent. The whole
> problem is that a page can only be in one place in the cache and if you
> randomly allocate pages when you build up objects, you'll get random
> likelihood that you are working on two (virtual) pages in your process
> that happen to be in the same location in the cache so they hammer each
> other.
>
> -
> 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/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNrYWAT7msCGEppcbAQEo7Af+PeCXTlTlnConF/TDDO5a1jimEMFvRq1e
65nm2qLFyjq0a1bCrDIMeKHV2381lRgU63BDmHsnJ09OC1IevewUIemiXdxjQR7U
Dl+HdXGXd9dPZ3fXSmiCz/l7hzOV3R8CCfqgdxllAwWWszVykvIOMhc7lvrIrzZD
oiKTh19/mh+h9hwusu+M8Zowypn0HDmgqbLRTjP08Eceak9HgYOZKzJUvExXHacY
Tx/CG+XLx2ukL/wv6JsJHG55wWMO7Tody4HhcNEdEr7to/0RhzvkBufgGyRzwLPk
jqnsx6U9uXtG4u5DlD3fwsgWN9OxceHYfDtELuWdqujuhRX+ePJg+g==
=eQNK
-----END PGP SIGNATURE-----
-
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/