From owner-freebsd-hackers  Thu Nov 23 13:26:14 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from cs.rice.edu (cs.rice.edu [128.42.1.30])
	by hub.freebsd.org (Postfix) with ESMTP
	id 85A1A37B4CF; Thu, 23 Nov 2000 13:26:11 -0800 (PST)
Received: (from alc@localhost)
	by cs.rice.edu (8.9.0/8.9.0) id PAA00745;
	Thu, 23 Nov 2000 15:26:10 -0600 (CST)
Date: Thu, 23 Nov 2000 15:26:10 -0600
From: Alan Cox <alc@cs.rice.edu>
To: Mike Smith <msmith@freebsd.org>
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
	hackers@freebsd.org
Subject: Re: page coloring
Message-ID: <20001123152610.F21300@cs.rice.edu>
References: <20001123143530.E21300@cs.rice.edu> <200011232048.eANKm9F01796@mass.osd.bsdi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5us
In-Reply-To: <200011232048.eANKm9F01796@mass.osd.bsdi.com>; from Mike Smith on Thu, Nov 23, 2000 at 12:48:09PM -0800
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, Nov 23, 2000 at 12:48:09PM -0800, Mike Smith wrote:
> > > Isn't the page coloring algoritm in _vm_page_list_find totally bogus?
> > > 
> > 
> > No, it's not.  The comment is, however, misplaced.  It describes
> > the behavior of an inline function in vm_page.h, and not the function
> > it precedes.
> 
> Hrm.  My comment was based on John Dyson's own observations on its 
> behaviour, and other discussions which concluded that the code wasn't 
> flexible enough (hardcoded assumptions on cache organisation, size etc.)
> 

Yes, it would be nice if it was "auto-configuring", because many people
who use it misconfigure it.  They configure the number of colors based
upon the size of their cache rather than cache size/degree of associativity.
(Having too many colors makes it less likely that you'll get a page
of the right color when you ask for one because that queue will be empty.)

Overall, it's my experience that people have absurb expectations
of page coloring.  They think of it as an optimization.  It's not.
It's better thought of as a necessary evil: Suppose you're writing
a numerical application and either you or your compiler goes
to a lot of trouble to "block" the algorithm for the L2 cache
size.  If the underlying OS doesn't do page coloring, it's likely
that your program will still experience conflict misses despite
your efforts to avoid them.  Furthermore, you'll see a different
number of conflict misses each time you run the program (assuming
the typical random page allocation strategies).  So, the execution
time will vary.  In short, page coloring simply provides a machine
whose performance is more deterministic/predictable.

Alan

P.S.  I noticed that I mistakenly cc'ed my previous message to -current
rather than -hackers.  I've changed it back to -hackers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message