public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wedgwood <cw@f00f.org>
To: ncw@axis.demon.co.uk
Cc: linux-kernel@vger.kernel.org
Subject: Re: "Colo[u]rs"
Date: Tue, 11 Dec 2001 06:52:39 +1300	[thread overview]
Message-ID: <20011210175239.GA13712@weta.f00f.org> (raw)
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> <1007972036.1237.36.camel@phantasy> <200112101222.fBACMFC17255@irishsea.home.craig-wood.com>
In-Reply-To: <200112101222.fBACMFC17255@irishsea.home.craig-wood.com>

On Mon, Dec 10, 2001 at 12:22:15PM +0000, ncw@axis.demon.co.uk wrote:

    Can you get colo[u]red memory from user-space?  This would be really
    useful for certain memory intensive applications (I'm thinking of
    large FFT users like mprime/ARMprime here)

By colored I assume you mean such that the pages are allocated to
process in such a way as to increase the cache's effectiveness (using
as many colors as possible and potentially not having too many
instances of the same color in successive pages)?

If so, then under Linux this is presently not possible and probably
never will be.  DaveM did some patches for this a while ago which is
of arguable use for things like sparc32 and MIPS, not sure about
sparc64.

SunOS and (I think) FreeBSD do take into account page coloring when
allocating memory though, I've told for some memory intensive MIPS
applications the performance difference can get as great as 15%, but
this is perhaps because of something else unique to MIPS (there are
ambiguities that mean only having one color present in the TLB for an
application at any one time solves).



  --cw

      reply	other threads:[~2001-12-10 17:50 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     ` "Colo[u]rs" Robert Love
2001-12-10 12:22       ` "Colo[u]rs" ncw
2001-12-10 17:52         ` Chris Wedgwood [this message]

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=20011210175239.GA13712@weta.f00f.org \
    --to=cw@f00f.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ncw@axis.demon.co.uk \
    /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