linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: Joakim Tjernlund <Joakim.Tjernlund@lumentis.se>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: MPC860 reorder and invalidate dcache
Date: Sat, 17 Aug 2002 09:33:02 -0400	[thread overview]
Message-ID: <3D5E508E.90504@embeddededge.com> (raw)
In-Reply-To: 002f01c245e2$de2223e0$0200a8c0@telia.com


Joakim Tjernlund wrote:

> We do  logging every 15 min and SW upgrades. It would be nice if this went a little faster.

Every 15 minutes seems like lots of activity for flash.  Better do some
math based upon your expected product lifetime and ensure the flash will
work for that many write cycles.   A few milliseconds every 15 minutes
doesn't seem to be worth special software.


> I read somewhere that the 'sync' instruction is an expensive one and I don't understand
> why it's used it in invalidate_dcache_range()

You are nit picking details that aren't likely to have any effect on your
system performance.  You need to use 'sync' to ensure the processor pipelines
are drained into cache before you push the lines to memory.  Ensure you have
considered what will happen to your application after you completely invalidate
the cache, as there is more stuff in there than the range of data buffers
you are considering.  It isn't very costly to scan the cache and discover there
isn't as much to be done.  It is more costly to invalidate lines you are using
and reload them.


> Our app consists of a lot of processes that mostly pass messages(UNIX sockets) between eachother.
> Do you think it's better to run the CPU in 66/66 MHz or (as we do today) 80/40 MHz?

You will have to test it with your application.  My experience has been the faster
core speed was always the winner.

> Would the "pinned TLB" mode be helpful(we have plenty of memory,128MB)?

Maybe.  Again you will have to test this.  With that much main memory it
may not be helpful because you have to cover so much kernel space with
page tables anyway.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-08-17 13:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-12 21:33 linuxppc_2_4_dev tree Cameron, Steve
2002-08-16 15:50 ` MPC860 reorder and invalidate dcache Joakim Tjernlund
2002-08-16 23:20   ` Dan Malek
2002-08-17 11:40     ` Joakim Tjernlund
2002-08-17 13:33       ` Dan Malek [this message]
2002-08-17 14:21         ` Joakim Tjernlund
2002-08-17 16:19           ` Dan Malek
2002-08-18 22:04             ` Joakim Tjernlund

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=3D5E508E.90504@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=Joakim.Tjernlund@lumentis.se \
    --cc=linuxppc-embedded@lists.linuxppc.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).