Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Feb 1999 10:15:31 -0500 (EST)
From:      "John S. Dyson" <dyson@iquest.net>
To:        dillon@apollo.backplane.com (Matthew Dillon)
Cc:        dyson@iquest.net, current@FreeBSD.ORG
Subject:   Re: Significant page coloring improvement
Message-ID:  <199902071515.KAA26836@y.dyson.net>
In-Reply-To: <199902071022.CAA20800@apollo.backplane.com> from Matthew Dillon at "Feb 7, 99 02:22:51 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said:
> 
> :	next_index += PQ_L2_SIZE/4;
> :	if (next_index > PQ_L2_MASK)
> :		next_index = (next_index + 1) & PQ_L2_MASK;
> 
>     Oops, make that:
> 
> 	next_index += PQ_L2_SIZE/4;
> 	if (next_index > PQ_L2_MASK)
> 		next_index = (next_index + PQ_PRIME1) & PQ_L2_MASK;
> 
>     Or even just:
> 
> 	next_index = (next_index + PQ_PRIME1) & PQ_L2_MASK;
> 
>     Both seem to work pretty well w/ lmbench, though nothing really sticks
>     its nose out.
> 
The reason why you might want to incr by PQ_L2_SIZE/N (or some other
large number) is that it will likely decrease conflicts for larger objects.

Note that the color should be chosen with more context (virtual address or
memory region type like shared lib) than I originally implemented.   There
are better approaches that take into consideration dynamic conflicts.  Such
dynamic conflicts might be more complex to determine, and a good static
choice adds only minimal overhead, yet provides some improvement.  I suggest
that until a major project can be undertaken, the static stuff is the right
thing.  It is easy to screw things up (as you can tell by my original
choice for coloring being suboptimal, but not necessarily destructive.)

I am agnostic regarding the coloring scheme, but I am glad that removing L1
coloring might be acceptable...  If anything, it will decrease instruction
cache footprint, and not cause a significant (hopefully any) decrease in
performance.

I will try to package up the patches (it is an issue of merging them in from
my codebase.)  They are essentially a result of hand optimizing the case of
setting PQ_L1_SIZE to 1.  Give me a day or so to put it together.

-- 
John                  | Never try to teach a pig to sing,
dyson@iquest.net      | it makes one look stupid
jdyson@nc.com         | and it irritates the pig.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



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