linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kenneth Johansson <kenneth@southpole.se>
To: linuxppc-dev@ozlabs.org
Subject: 5121 cache handling.
Date: Fri, 07 Aug 2009 14:53:52 +0200	[thread overview]
Message-ID: <1249649632.4940.38.camel@localhost> (raw)

on 5121 there is a e300 core that unfortunately is connected to the rest
of the SOC with a bus that do not support coherency.

solution for many driver has been to use uncached memory. But for the
framebuffer that is not going to work as the performance impact of doing
graphics operations on uncached memory is to large.

currently the "solution" is to flush the cache in the interrupt
handler. 

#if defined(CONFIG_NOT_COHERENT_CACHE)
                        int i;
                        unsigned int *ptr;
                        ptr  = coherence_data;
                        for (i = 0; i < 1024*8; i++)
                                *ptr++ = 0;
#endif

Now this apparently is not enough on a e300 core that has a PLRU cache
replacement algorithm. but what is the optimal solution? 

should not the framebuffer be marked as cache write through. that is the
W bit should be set in the tlb mapping. Why is this not done ? is that
feature also not working on 5121 ??

if this manual handling needs to be done what is best. 

do it like now but over 52KB memory basically throwing out anything in
the cache in the process regardless if it was needed or not.

or do it carefully over just the framebuffer memory.

problem with doing it over just the framebuffer is that a 1024x768
buffer is 98304 cache lines it's going to take a considerable time to
do. how many cycles does it take per cache line if we never get a hit ??
3cycles at 400MHz gives 4.5milisec/sec or 4-5% overhead

1024*768*4/32*3*(1/400000000)*60
.04423680000000000000

52kB on the other hand is only 1664 lines but is obviously going to have
to do a lot of actual memory writes also for any modified cache line and
later a lot of reads to read back what was evicted. 

             reply	other threads:[~2009-08-07 12:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-07 12:53 Kenneth Johansson [this message]
2009-08-07 19:56 ` 5121 cache handling Scott Wood
2009-08-10 20:16   ` Kenneth Johansson
2009-08-10 20:26     ` Scott Wood
2009-08-10 20:45       ` Kenneth Johansson
2009-08-10 20:49         ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1249649632.4940.38.camel@localhost \
    --to=kenneth@southpole.se \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).