From: Robert Love <rml@tech9.net>
To: Stevie O <stevie@qrpff.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: "Colo[u]rs"
Date: 10 Dec 2001 03:13:55 -0500 [thread overview]
Message-ID: <1007972036.1237.36.camel@phantasy> (raw)
In-Reply-To: <5.1.0.14.2.20011210024959.01c81c20@whisper.qrpff.net>
In-Reply-To: <5.1.0.14.2.20011210020236.01cca428@whisper.qrpff.net> <5.1.0.14.2.20011210020236.01cca428@whisper.qrpff.net> <5.1.0.14.2.20011210024959.01c81c20@whisper.qrpff.net>
On Mon, 2001-12-10 at 03:00, Stevie O wrote:
> For the n-way associative deal:
If the cache is n-way associative, it can store n lines at each
mapping. So even though two virtual addresses map to the same cache
line, they can both be stored. Of course, if you have k addresses such
that k>n, then you reach the same problem as direct map (the case where
n=1) caches.
To reiterate, the point of coloring would be to prevent the case of
multiple addresses mapping to the same line. Let me give you a
real-life example. We recently have been trying to color the kernel
stack. If every process's stack lies at the same address (let alone the
same page multiple and offset), then they all map to the same place in
the cache and we can effectively only cache one of them (and
subsequently cache miss on every other access). If we "color" the
location of the stack, we make sure they don't all map to the same
place. This obviously involves some knowledge of the cache system, but
it tends to be general enough that we can get it right for all cases.
If you are _really_ interested in this, an excellent and very thorough
book is UNIX Systems for Modern Architectures: Symmetric Multiprocessing
and Caching for Kernel Programmers, by Curt Schimmel.
Robert Love
next prev parent reply other threads:[~2001-12-10 8:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200112100656.fBA6ukA14374@www.hockin.org>
2001-12-10 7:07 ` "Colo[u]rs" Stevie O
2001-12-10 7:26 ` "Colo[u]rs" Robert Love
2001-12-10 7:36 ` "Colo[u]rs" Robert Love
2001-12-10 7:28 ` "Colo[u]rs" Larry McVoy
2001-12-10 7:21 ` "Colo[u]rs" David Lang
2001-12-10 7:51 ` "Colo[u]rs" Larry McVoy
2001-12-10 7:30 ` "Colo[u]rs" David Lang
2001-12-10 7:33 ` "Colo[u]rs" Stevie O
2001-12-10 8:37 ` "Colo[u]rs" Alan Cox
2001-12-10 8:00 ` "Colo[u]rs" Stevie O
2001-12-10 8:13 ` Robert Love [this message]
2001-12-10 12:22 ` "Colo[u]rs" ncw
2001-12-10 17:52 ` "Colo[u]rs" Chris Wedgwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1007972036.1237.36.camel@phantasy \
--to=rml@tech9.net \
--cc=linux-kernel@vger.kernel.org \
--cc=stevie@qrpff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox