From owner-freebsd-current@FreeBSD.ORG Mon Jun 21 06:11:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB18416A4CE for ; Mon, 21 Jun 2004 06:11:39 +0000 (GMT) Received: from VARK.homeunix.com (c-67-174-240-84.client.comcast.net [67.174.240.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BFC243D4C for ; Mon, 21 Jun 2004 06:11:39 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i5L6BVS6001172; Sun, 20 Jun 2004 23:11:31 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i5L6BVmi001171; Sun, 20 Jun 2004 23:11:31 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 20 Jun 2004 23:11:30 -0700 From: David Schultz To: Alexander Leidinger Message-ID: <20040621061130.GB927@VARK.homeunix.com> Mail-Followup-To: Alexander Leidinger , current@FreeBSD.ORG References: <20040616112758.46677e25@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040616112758.46677e25@Magellan.Leidinger.net> cc: current@FreeBSD.ORG Subject: Re: How to determine the L2 cache size on non-AMD CPUs (automatic page queue color tuning)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 06:11:39 -0000 On Wed, Jun 16, 2004, Alexander Leidinger wrote: > I'm working with Alan and Chad David on automatic tuning of the number > of colors for the page queue. For AMD CPUs (including amd64, but not > tested) we already have code in identcpu.c to determine the size of the > L2 cache and its associativity. I instrumented the page coloring code a while ago, and found that it actually didn't work as effectively as it was supposed to. For instance, when there are 256 colors, the `incr' used in _vm_object_allocate() is not relatively prime to the number of colors, so a given vm_object only gets 1/4 of the colors it should. Nevertheless, fixing that problem resulted in a performance increase that I was barely able to measure. Associativity and victim caching virtually eliminate the benefits of page coloring on modern architectures. Moreover, there's an easier way to do page coloring that will work on every architecture without you having to figure out the appropriate number of colors! Specifically, you pick a fixed number of bins N that's as big as the widest cache you intend to support, and do the coloring hierarchically. If you search the bins in the right order, you get a coloring that's optimal for caches of size N, but also for caches of size N/2, N/4, etc. The great things about this technique are that it's fast for reasonably-sized N, it is cache size independent, and it requires only minor changes to _vm_pageq_find(). See the following paper: http://citeseer.ist.psu.edu/kessler92page.html