Flushing data cache on PPC405 in Linux

Flushing data cache on PPC405 in Linux

[John Linn]

I have a situation that requires a flush the data cache at specific time
periods to help with memory scrubbing.

On the 405, I don't see any easy way to do this since you don't know
what the cache has in it and there's not an instruction to flush the
whole cache.  It looks like a kernel driver is needed to map pages then
flush that data cache for the pages. =


I'm concerned there will be side affects I don't realize as I'm assuming
the driver would slowly go thru all of physical memory mapping pages
(cached or non-cached) and then flushing all addresses in the page(s).

Any thoughts?

Thanks,
John

This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Flushing data cache on PPC405 in Linux

[Dan Malek]

Hi John.

On Feb 23, 2011, at 5:04 PM, John Linn wrote:

> Any thoughts?

I can come up with two methods, but before I describe them
ensure you consider the actual implementation of your 405 core.
My comments are based on the "standard" ppc405 processor,
but since you can configure the embedded cores to your liking,
the cache size may be different that the 16K bytes on the old
processor.

Method one.  Just 'memset()' 16K of data that will replace all cache
lines and push out modified lines.  This 16K must be physically
contiguous, so allocate in your favorite way, with with the cache
coherent DMA functions, bootmem, reserved, whatever.  Just
ensure that this 16K is also cached, as I've implemented
dma_cache_coherent into uncached VM space in the past :-)

Method two.  Use 'dcread' to read the cache tags.  If the line is
modified, form an EA that will match that line and 'dcbf' the line.
This is a little more tricky because the tags are physical addresses,
so you would need to do this with the MMU disabled to ensure
the physical EA you generated also hits the cache.  The upside
is you only perform the actual required flush operations, and you
didn't blow the cache away requiring a refill latency.

Have fun!

	-- Dan

RE: Flushing data cache on PPC405 in Linux

[John Linn]

> -----Original Message-----
> From: Dan Malek [mailto:ppc6dev@digitaldans.com]
> Sent: Wednesday, February 23, 2011 8:39 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Flushing data cache on PPC405 in Linux
> =

> =

> Hi John.
> =

> On Feb 23, 2011, at 5:04 PM, John Linn wrote:
> =

> > Any thoughts?
> =

> I can come up with two methods, but before I describe them
> ensure you consider the actual implementation of your 405 core.
> My comments are based on the "standard" ppc405 processor,
> but since you can configure the embedded cores to your liking,
> the cache size may be different that the 16K bytes on the old
> processor.
> =

> Method one.  Just 'memset()' 16K of data that will replace all cache
> lines and push out modified lines.  This 16K must be physically
> contiguous, so allocate in your favorite way, with with the cache
> coherent DMA functions, bootmem, reserved, whatever.  Just
> ensure that this 16K is also cached, as I've implemented
> dma_cache_coherent into uncached VM space in the past :-)

Awesome Dan, that seems reasonable to me and much easier than I was
thinking :)

I was obviously making it harder than it had to be as usual. Seems like
I can just kmalloc the memory then memset it. =


Appreciate the help and suggestions.

-- John

> =

> Method two.  Use 'dcread' to read the cache tags.  If the line is
> modified, form an EA that will match that line and 'dcbf' the line.
> This is a little more tricky because the tags are physical addresses,
> so you would need to do this with the MMU disabled to ensure
> the physical EA you generated also hits the cache.  The upside
> is you only perform the actual required flush operations, and you
> didn't blow the cache away requiring a refill latency.
> =

> Have fun!
> =

> 	-- Dan
> =



This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

RE: Flushing data cache on PPC405 in Linux

[John Linn]

> -----Original Message-----
> From: John Linn
> Sent: Thursday, February 24, 2011 7:15 AM
> To: 'Dan Malek'
> Cc: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca
> Subject: RE: Flushing data cache on PPC405 in Linux
> =

> > -----Original Message-----
> > From: Dan Malek [mailto:ppc6dev@digitaldans.com]
> > Sent: Wednesday, February 23, 2011 8:39 PM
> > To: John Linn
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: Flushing data cache on PPC405 in Linux
> >
> >
> > Hi John.
> >
> > On Feb 23, 2011, at 5:04 PM, John Linn wrote:
> >
> > > Any thoughts?
> >
> > I can come up with two methods, but before I describe them
> > ensure you consider the actual implementation of your 405 core.
> > My comments are based on the "standard" ppc405 processor,
> > but since you can configure the embedded cores to your liking,
> > the cache size may be different that the 16K bytes on the old
> > processor.
> >
> > Method one.  Just 'memset()' 16K of data that will replace all cache
> > lines and push out modified lines.  This 16K must be physically
> > contiguous, so allocate in your favorite way, with with the cache
> > coherent DMA functions, bootmem, reserved, whatever.  Just
> > ensure that this 16K is also cached, as I've implemented
> > dma_cache_coherent into uncached VM space in the past :-)
> =

> Awesome Dan, that seems reasonable to me and much easier than I was
thinking :)
> =

> I was obviously making it harder than it had to be as usual. Seems
like I can just kmalloc the memory
> then memset it.

It seems like this also depends on that fact that __GFP_COLD will work,
otherwise some of the data could =

already be in the cache such that you're not guaranteed to get
everything out of the cache.

Do we know that works on arch/powerpc, or I'm not understanding it
right?  I'm doing some digging to make sure.

Thanks,
John

> =

> Appreciate the help and suggestions.
> =

> -- John
> =

> >
> > Method two.  Use 'dcread' to read the cache tags.  If the line is
> > modified, form an EA that will match that line and 'dcbf' the line.
> > This is a little more tricky because the tags are physical
addresses,
> > so you would need to do this with the MMU disabled to ensure
> > the physical EA you generated also hits the cache.  The upside
> > is you only perform the actual required flush operations, and you
> > didn't blow the cache away requiring a refill latency.
> >
> > Have fun!
> >
> > 	-- Dan
> >


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Flushing data cache on PPC405 in Linux

[Dan Malek]

On Feb 24, 2011, at 6:43 AM, John Linn wrote:

> It seems like this also depends on that fact that __GFP_COLD will  
> work,
> otherwise some of the data could
> already be in the cache such that you're not guaranteed to get
> everything out of the cache.

I wouldn't count on GFP_COLD as a guarantee the data isn't
in the cache.  It's likely, but the generic MM functions just
ensures they are old pages, based on an indication from the
caller that freed the pages.


	-- Dan