Re: kern/45361

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

The following reply was made to PR kern/45361; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: mrg%eterna.com.au@localhost
Cc: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: kern/45361
Date: Tue, 15 Nov 2011 19:30:56 +0900

 > if there are other problems without PRs occuring, they should be
 > given new PRs.  ie, don't confuse multiple issues in the same PR.
 
 I think current page coloring code should be reorganized.
 
 Page coloring was introduced by thorpej back in 2001
 for PIPT cache to avoid cache index thrashing.
 It tries to allocate different color pages from the previous
 one on large (up to 64~128 colors) PIPT L2 cache systems.
 (as uvm_page.c:uvm_pagealloc_pgfl() does)
 http://mail-index.netbsd.org/source-changes/2001/04/29/0007.html
 
 On the other hand, recently committed page coloring code is
 for VIPT cache to avoid aliasing, which tries to allocate
 a same color page as specified one.
 
 It looks the problem is that uvmexp.ncolors is used for
 both VA cache page colors and PA cache page colors,
 i.e. unnecessary COLORMATCH (which is for VIPT) is specified
 even on PIPT cache systems. I don't think extra pages
 for emergeva (and emerg_recolor) are necessary on PIPT including
 x86 either. It's really silly to allocate 32~64 4KB pages
 for 64KB buffer, isn't it?
 
 Usually VIPT systems have only 2~4 colors (32KB L1 with 2 set associative
 for example) so it's better to reserve possible maximum pages for
 a number of colors on initial emageva allocation for VIPT systems,
 rather than to have complicated emerge_recolor().
 
 ---
 Izumi Tsutsui