yes, I mean vm_page_t, and understand what you said. I will try to print the
value of PQ_L2_SIZE in my kernel. Do you know what kernel options influence
this value? I saw it is decided by PQ_CACHESIZE which is decided by different
PQ_HUGE[LARGE/MEDIUM/...]CACHE....setting. Default setting PQ_CACHESIZE is 128,
and corresponding PQ_L2_SIZE is 32. Am I right until now or something wrong?
I use FreeBSD 4.1 release kernel to build my kernel.
Anyway, thanks for your explaination.
Rex Luo
Matt Dillon <[EMAIL PROTECTED]> said:
>
> :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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
