Re: PA caches (was: C8000 cpu upgrade problem)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2010-10-27 at 18:28 +0200, Mikulas Patocka wrote:
> 
> On Wed, 27 Oct 2010, James Bottomley wrote:
> 
> > On Wed, 2010-10-27 at 10:06 +0200, Mikulas Patocka wrote:
> > > 
> > > On Tue, 26 Oct 2010, James Bottomley wrote:
> > > 
> > > > On Tue, 2010-10-26 at 21:29 -0400, John David Anglin wrote:
> > > > > > - shared memory --- there is SHMLBA boundary that causes that all
> > > > > mappings 
> > > > > > are aligned to this boundary --- it is **WRONG** in the current
> > > > > kernel!!! 
> > > > > > It is only 4MB and should be 16MB!!!
> > > > > 
> > > > > James has said that the max for all PA-RISC implementations is
> > > > > 4 MB.  The value is returned by the PDC_CACHE call.  Maybe a BUG_ON is
> > > > > called for.  The alias boundary can be determined by the alias field
> > > > > in the D_conf return value.
> > > > 
> > > > Why is it I get blamed for everything cache related on parisc?  The
> > > 
> > > You don't get blamed, we're just trying to find bugs :)
> > > 
> > > > statement in the manuals that the equivalency modulus is 16MB was left
> > > > for future expansion.  However, given PA8900 is the last in the series,
> > > > there is no future expansion.  John Marvin (I think it was) from the HP
> > > > processor group confirmed that the largest equivalency modulus for any
> > > > produced parisc processor is 4MB, so that's what we use in the kernel.
> > > > 
> > > > James
> > > 
> > > The largest L2 cache size is 64MB --- so if the cache is 4-way 
> > > associative, the equivalency distance is 16MB (as the manual says).
> > > 
> > > If the equivalency distance were 4MB, the L2 cache would have to be 16-way 
> > > (or the cache would have to be physically indexed and you wouldn't have to 
> > > care about its consistency at all).
> > 
> > The L2 cache has no equivalency modulus ... it's not virtually indexed.
> > 
> > James
> 
> Why is Kyle than suggesting that I am lucky because I have no L2 cache 
> (and therefore, Linux runs faster)?
> 
> Why are people talking here about flushing 32MB or 64MB L2 on fork()?
> 
> Or is it that you need to flush only L1 cache but the architecture forces 
> flush of both caches?

There's only a couple of flush instructions: fic and fdc ... they have
to flush all caches.  We did argue the toss on this with the HP
processor people since aliasing, which is primarily where we need
flushes for control, only occurs in the L1 cache.  However, they pointed
out that if they made fic and fdc L1 specific, we'd have no control over
DMA type ops which have to reach physical memory.

> I'd still like to see if someone with PA8800 or PA8900 with L2 ran that 
> shared memory experiment to actually *prove* that L2 is physically indexed 
> and that the L1 equivalency modulus is 4MB. I.e. not rely on what you 
> heard somewhere, but rely on what you see.

We already did all of that years ago just trying to make the pa8x00
chips work with linux ... they didn't for about 18 months.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux