public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Larry McVoy <lm@bitmover.com>
To: Stevie O <stevie@qrpff.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: "Colo[u]rs"
Date: Sun, 9 Dec 2001 23:28:59 -0800	[thread overview]
Message-ID: <20011209232859.I25754@work.bitmover.com> (raw)
In-Reply-To: <5.1.0.14.2.20011210020236.01cca428@whisper.qrpff.net>
In-Reply-To: <5.1.0.14.2.20011210020236.01cca428@whisper.qrpff.net>; from stevie@qrpff.net on Mon, Dec 10, 2001 at 02:07:06AM -0500

On Mon, Dec 10, 2001 at 02:07:06AM -0500, Stevie O wrote:
> After a few failed web searches (combos like 'linux cache color' just gave 
> me a bunch of references to video), I am resorting to this list for this 
> question.
> 
> What exactly do y'all mean by these "colors"? Task colors, cache colors, 
> and probably a few other colors i've missed/forgotten about. What do these 
> colors represent? How are they used to group tasks/cache entries? Is what 
> they're actually for?

Coloring usually means the laying out of data such that the data will 
not collide in the cache, usually the second (or third) level cache.

Data references are virtual, most caches are physically tagged.  That 
means that where data lands in the cache is a function of the physical
page address and offset within that page.  If the cache is what is called
direct mapped, which means each address has exactly one place it can be
in the cache, then page coloring becomes beneficial.  More on that in
a second.  Most caches these days are set associative, which means there
are multiple places the same cache line could be.  A 2 way set associative
cache means there are 2 places, 4 way means there are 4, and so on.  The
trend is that the last big cache before memory is at least 2 way and more
typically 4 way set associative.  There is a cost with making it N-way
associative, you have to run all the tag comparitors in parallel or
you have unacceptable performance.  With shrinking transistors and high
yields we are currently enjoying, the costs are somewhat reduced.

So what's page coloring?  Suppose we have a 10 page address space and
we touch each page.  As we touch them, the OS takes a page fault, grabs
a physical page, and makes it part of our address space.  The actual
physical addresses of those pages determine where the cache lines
will land in the cache.  If the pages are allocated at random, worst
case is that all 10 pages will map to the same location in the cache,
reducing the cache effectiveness by 10x assuming a direct mapped cache,
where there is only one place to go.   Page coloring is the careful
allocation of pages such that each virtual page maps to a physical page
which will be at a different location in the cache.  Linus doesn't like
it because it adds cost to the page free/page alloc paths, they now have
to go put/get the page from the right bucket.  He also says it's pointless
because the caches are becoming enough associative that there is no need
and he's mostly right.  Life can really suck on small cache systems that
are direct mapped, as are some embedded systems, but that's life.  It's
a tradeoff.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

  parent reply	other threads:[~2001-12-10  7:29 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   ` Larry McVoy [this message]
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     ` "Colo[u]rs" Robert Love
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=20011209232859.I25754@work.bitmover.com \
    --to=lm@bitmover.com \
    --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