From: epsi@gmx.de
To: "Woodruff, Richard" <r-woodruff2@ti.com>,
linux-omap@vger.kernel.org, premi@ti.com
Subject: Re: RE: RE: Memory performance / Cache problem
Date: Wed, 14 Oct 2009 16:48:39 +0200 [thread overview]
Message-ID: <20091014144839.115530@gmx.net> (raw)
In-Reply-To: <13B9B4C6EF24D648824FF11BE8967162039B235D5C@dlee02.ent.ti.com>
Mem clock is both times 166MHz. I don't know whether are differences in cycle access and timing, but memclock is fine.
Following Siarhei hints of initialize the buffers (around 1.2 MByte each)
I get different results in 22kernel for use of
malloc alone
memcpy = 473.764, loop4 = 448.430, loop1 = 102.770, rand = 29.641
calloc alone
memcpy = 405.947, loop4 = 361.550, loop1 = 95.441, rand = 21.853
malloc+memset:
memcpy = 239.294, loop4 = 188.617, loop1 = 80.871, rand = 4.726
In 31kernel all 3 measures are about the same (unfortunatly low) level of malloc+memset in 22.
First of all: What performance can be expected?
Does 22 make failures if it is so much faster?
Can the later kernels get a boost in memory handling?
I used a standard memcpy (think this is glib and hence not neonbased)?
To be neonbased I guess it has to be recompiled?
How can I find out that neon and cache settings are ok?
Using a Omap3530 on EVM board
Unfortunatly I don't have a Lauterbach, just a Spectrum Digital which works only until Linux kernel is booting.
Best regards
Steffen
-------- Original-Nachricht --------
> Datum: Wed, 14 Oct 2009 08:59:05 -0500
> Von: "Woodruff, Richard" <r-woodruff2@ti.com>
> An: "epsi@gmx.de" <epsi@gmx.de>, "Premi, Sanjeev" <premi@ti.com>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
> Betreff: RE: RE: Memory performance / Cache problem
> > There is no newer u-boot from TI available. There is a SDK 02.01.03.11
> > but it contains the same uboot 2008.10 with the only addition of the
> second
> > generation of EVM boards with another network chip.
> >
> > So I checked the uboot from git, but this doesn't support Microns NAND
> Flash
> > anymore. It is just working with ONENAND.
> >
> > I found a patch which shows the L2 Cache status while kernel boot and
> > implemented it : L2 Cache seems to be already enabled - so this is not
> the
> > reason.
> >
> > So any other ideas?
>
> Are you confident your memory bus isn't running at 1/2 speed?
>
> I recall there was a couple day window during wtbu kernel upgrades where
> memory bus speed with pm was running 1/2 speed after kernel started up.
> This was somewhat a side effect of constraints frame work and a regression in
> forward porting. It seems unlikely psp kernel would have shipped with this
> bug but its something to check. This would match your results.
>
> If your memcpy() is neon based then I might be worried about
> l1neon-caching effects along with factors of (exlcusive-l1-l2-read-allocate cache + pld
> not being effective on l1 only l2).
>
> Which memcpy test are you using? Something in lmbench or just one you
> wrote. Generally results are a little hard to interpret with exclusive cache
> behavior in 3430's r1px core. 3630's r3p2 core gives more traditional
> results as exclusive feature has been removed by arm.
>
> If you have the ability using Lauterbach + per file will allow internal
> space dump which will show all critical parameters during test. It's a 1
> minute check for someone who has done it before to ensure the few parameters
> needed are in line. I can send an example off line of how to do capture. I
> won't have time to expand on all relevant parameters.
>
> Regards,
> Richard W.
--
Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!
http://portal.gmx.net/de/go/dsl02
next prev parent reply other threads:[~2009-10-14 14:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-12 8:38 Memory performance / Cache problem epsi
2009-10-12 9:07 ` Dasgupta, Romit
2009-10-12 9:51 ` Dasgupta, Romit
2009-10-12 9:12 ` Premi, Sanjeev
2009-10-13 8:16 ` epsi
2009-10-14 13:59 ` Woodruff, Richard
2009-10-14 14:48 ` epsi [this message]
2009-10-14 15:25 ` Woodruff, Richard
2009-10-14 17:23 ` epsi
2009-10-14 17:36 ` Woodruff, Richard
2009-10-14 17:37 ` Siarhei Siamashka
2009-10-14 17:46 ` Woodruff, Richard
2009-10-15 10:20 ` epsi
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=20091014144839.115530@gmx.net \
--to=epsi@gmx.de \
--cc=linux-omap@vger.kernel.org \
--cc=premi@ti.com \
--cc=r-woodruff2@ti.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.