[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
The following reply was made to PR kern/45361; it has been noted by GNATS.
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@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)
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().
Main Index |
Thread Index |