From owner-freebsd-hackers Thu Jul 26 0:20:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 512E837B405 for ; Thu, 26 Jul 2001 00:20:20 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6Q7KFv54874; Thu, 26 Jul 2001 00:20:15 -0700 (PDT) (envelope-from dillon) Date: Thu, 26 Jul 2001 00:20:15 -0700 (PDT) From: Matt Dillon Message-Id: <200107260720.f6Q7KFv54874@earth.backplane.com> To: Rex Luo Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: qestion about vm page coloring References: <200107260408.MAA08931@synology.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Dear all, : : I study FreeBSD vm managememnt recently, however, I am a little confused :with vm_page's page color. when you call vm_add_new_page() in vm_startup(), :you will set each map entry's page color according to its physical addr. : : m->pc = (pa >> PAGE_SHIFT)&PQ_L2_MASK; : :However, I found that almost each map entry's page color is zero, that means :PQ_L2_SIZE is 1, and disable page coloring option. Maybe I can do some :modification to dump PQ_L2_SIZE's value, but I think my guess is right. :Can someone please tell me the principle of page coloring, and why it's disabled :now? : :Thanks, : :Rex Luo I'm not sure what you mean by 'map entry'... vm_page_t's have color, and vm_object's have a base color to randomly offset the color of the vm_page_t's associated with the object, but vm_map_entry's do not have a page color associated with them. The page coloring works fine on my box, you may be looking at the wrong thing. PQ_L2_SIZE is definitely not 1 unless you've specified some weird kernel options in the kernel config. - Page coloring basically ensures that pages which are adjacent in virtual memory also wind up being adjacent in the L1 and L2 cpu caches in order to get more consistent cpu cache behavior. Without page coloring it is quite possible to have several adjacent pages in virtual memory wind up utilizing the same cpu cache page, which can effect performance with certain types of applications or certain cpu cache topologies. On IA32 pentium architectures the effect would probably not be all that noticeable, but getting consistent behavior is still a good thing. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message