The way i undestand it so far, is:
each line in the cache will map to a block of memory addresses -
naturally, or else we'd have as much cache as memory. the way
it's mapped is determined by your hardware.
now if we have a programme with X physical pages, in order to get
the most benefit from the cache, we would want to arrange our X
physical pages in main memory so that we use as many cache lines
as possible.
the alternative is that we arrange the X pages such that they all
end up in physical memory that is cached by the same cache line.
Which would result in your programme not benefitting from cache
at all - as each succesive page would not be in cache, and would
have to be loaded from main memory. The process would clobber the
same cache line over and over again.
ie X pages all being cached by the same 32 byte (on intel) cache
line.
Linux at the moment randomly allocates physical pages, and this
can result in programmes sometimes running in the latter way.
Page coloring seems to be about allocating physical pages for
processes in a more ordered way, such that it optimises the use
of cache.
ie in the case of set associative cache, by spreading the pages
evenly around memory, the chances are that more of a processes
physical pages will be covered by more cache lines.
So our X pages would be in memory such that they are covered by
eg 60% of the cache lines. (which would be about 600Kb on my
super7 motherboard)
(most hardware cache algorithms are a variation of n-way set
associative, i believe.. i think.. :) )
that's my non-kernel hacker view of it anyway... :)
On Mon, 1 Feb 1999, David Lang wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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?
hth.
regards,
-- Paul Jakma paul@clubi.ie PGP5 key: http://www.clubi.ie/publickey.txt -------------------------------------------A bureaucrat's idea of cleaning up his files is to make a copy of everything before he destroys it.
- 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/