public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: lm@bitmover.com (Larry McVoy)
To: linux-kernel@vger.rutgers.edu
Subject: Re: Page coloring HOWTO [ans]
Date: Sat, 30 Jan 1999 16:04:51 -0800	[thread overview]
Message-ID: <199901310004.QAA01165@bitmover.com> (raw)

Richard Gooch <rgooch@atnf.csiro.au>:
: > : >     (a) make sure that each process maps the same virtual addresses to 
: > : >         different locations in the cache, if possible.
: > : 
: > : >     (b) make sure that a contiguous chunk of virtual address space in
: > : >         one process occupies a contiguous chunk of cache, if possible.
: 
: OK, I was reading points (a) and (b) as though they were, in effect,
: the required specificiations for an algorithm to yield the best
: pages. Are they just comments on how the particular algorithm you
: mentioned works?
: 
: I'd like to speparate this into two issues. Firstly, requirements on
: how to lay out physical pages to minimise cache line aliasing.

Huh?  Direct mapped caches are all virtually indexed and physically
tagged, if I remember correctly.  Regardless, the buckets into which the
pages are sorted are set up such that if you were to allocate one page
from each bucket, then all of the pages would land in different chunks
of the cache by definition.   That's why you hash on physical addresses
when sorting the pages.

When looking for a page, you hash on the process' virtual address (plus
pid offset) because you have to have something, and what else are you
going to use?  That's the only deterministic thing you have.

: For the former issue, I'd like to establish whether you are saying
: that points (a) and (b) provide better pages than the simple "add plus
: modulus" scheme of generating goal colours?

It's not a question of "better", it's a question of "correct".  And you
don't generate colors for the physical pages except when you put them
in the buckets.  

I think you are mixing up the virtual addresses and physical addresses in
your thinking.  Do you a copy of Hennessy and Patterson?  I'm sure they 
talk about this or provide a pointer to a paper on 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/

             reply	other threads:[~1999-01-30 23:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-31  0:04 Larry McVoy [this message]
1999-01-31  7:25 ` Page coloring HOWTO [ans] David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
1999-01-31  8:47 Colin Plumb
1999-01-31 19:24 Larry McVoy
1999-01-31 22:05 ` Steve VanDevender
1999-02-01  7:20 ` David S. Miller
     [not found] <"4S1CG3.0.Tz5.-gvis"@tequila.cs.yale.edu>
1999-02-01 23:11 ` Stefan Monnier

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=199901310004.QAA01165@bitmover.com \
    --to=lm@bitmover.com \
    --cc=linux-kernel@vger.rutgers.edu \
    /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