Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jul 2001 00:20:15 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Rex Luo <rexluo@synology.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: qestion about vm page coloring
Message-ID:  <200107260720.f6Q7KFv54874@earth.backplane.com>
References:   <200107260408.MAA08931@synology.com>

next in thread | previous in thread | raw e-mail | index | archive | help

: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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107260720.f6Q7KFv54874>