From owner-freebsd-current Thu Jul 30 22:04:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA01277 for freebsd-current-outgoing; Thu, 30 Jul 1998 22:04:24 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA01272 for ; Thu, 30 Jul 1998 22:04:22 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from aura.rice.edu (aura.rice.edu [192.136.146.26]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id AAA24159; Fri, 31 Jul 1998 00:04:16 -0500 (CDT) Received: from aura.rice.edu (localhost [127.0.0.1]) by aura.rice.edu (8.8.8/8.7.3) with ESMTP id AAA01896; Fri, 31 Jul 1998 00:04:16 -0500 (CDT) Message-Id: <199807310504.AAA01896@aura.rice.edu> To: bde@zeta.org.au cc: current@FreeBSD.ORG Subject: Re: using vm_page.h in userland program Date: Fri, 31 Jul 1998 00:04:15 -0500 From: Alan Cox Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -------- > The cache coloring options should be dynamic anyway. I have tried a few > different values on various machines but didn't notice much difference > and didn't have time to do careful comparisons. Its main effect is to reduce the variation in execution time between one run and another because all of the runs will experience (almost) the same set of conflict misses. To actually see the effects, try running the lmbench memory read latency test. With appropriate page coloring, you get a nice step function as you fall out of L1 cache into L2 cache and then main memory. Without the correct page coloring you get spikes where there shouldn't be. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message