[Top] [All Lists]

Re: c-r4k.c cleanup

To: Dominic Sweetman <>
Subject: Re: c-r4k.c cleanup
From: Ralf Baechle <>
Date: Fri, 4 Feb 2005 16:45:32 +0100
Cc: Nigel Stephens <>, Atsushi Nemoto <>,
In-reply-to: <16899.37525.412441.558873@gargle.gargle.HOWL>
Original-recipient: rfc822;
References: <> <> <> <16899.37525.412441.558873@gargle.gargle.HOWL>
User-agent: Mutt/1.4.1i
On Fri, Feb 04, 2005 at 03:19:49PM +0000, Dominic Sweetman wrote:

> Only some CPUs suffer from aliases.  A 4Kbyte direct-mapped cache must
> be alias free, because all the virtual index bits are the same (being
> in-page) as the physical address bits.  That's true but irrelvant,
> since there aren't any 4Kbyte caches: but what's slightly less obvious
> is that a 16Kbyte 4-way set-associative cache is also alias free.

I had dark memory of some el cheapo CPU having 4k caches.

> 24K's "AR" bit trick applies *only* to the D-cache, and only to a
> 32Kbyte cache.  (But then most alias problems are D-cache aliases, and
> 32Kbyte happens to be the most popular size for a 24K cache - so this
> is a trick worth doing).
> Note that I-cache aliases are not completely harmless; sometimes you
> want to invalidate any I-cache copies of some data, and if it's
> aliased you may miss some of them.  Shared libraries are generally
> aligned to some large page-size multiple - so multiple text images are
> usually the same colour, and don't matter.  You can get problems with
> trampolines and stuff.

Linux computes the necessary alignment on the fly.  The method used is
not strictly correct because as you say it should account for possible
I-cache aliases also.

Seems it's cache day again today ;-)


<Prev in Thread] Current Thread [Next in Thread>