All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ayman El-Khashab <ayman@elkhashab.com>
To: linuxppc-dev@ozlabs.org
Subject: Help with finding memory read performance problem
Date: Thu, 16 Sep 2010 15:12:20 -0500	[thread overview]
Message-ID: <20100916201220.GC18608@crust.elkhashab.com> (raw)



For our code we needed a fast memory compare of 5 buffers.  I've implemented
said routine in asm and it works fine and is very fast in the test bench. 
However when integrated with the app it is much less performant and we 
are trying to figure out why.

The app in question gets the 5 4MB buffers in the kernel via kmalloc and
then uses them for DMA.  No other methods are being called for the memory
besides kmalloc.  This is an embedded system on the 460EX, so there is no
drive, only RAM.  Within the user code mmap is called on these buffers
physical address and they are given to the compare routine.  The result 
is slow.  If I allocate buffers in user space then the performance is
excellent.  

Next I implemented my compare routine within a kernel module so that it
was using the kernel virtual addresses for each of the buffers. I did 
not see any change between this and the mmap approach.  

For comparison sake, using the kernel memory is about 19s whereas user
memory is about 11s for the same size / configuration of buffer.  In the
test bench the algorithm is about 8s.  The processor is not doing any
other intensive tasks during these tests and the times are repeatable.

Is something happening to mmap'd memory that causes the access to it to
be slow?  Is there a way to speed that up?  Why are the kernel memory
access slower than user memory?  

What is the best overall approach?  Is it to DMA into user memory and
then run the routines there?  Is kmalloc not the best approach for 
kernel DMA memory?

This is on linux 2.6.31.5 on 460EX

thanks
ayman

                 reply	other threads:[~2010-09-16 20:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20100916201220.GC18608@crust.elkhashab.com \
    --to=ayman@elkhashab.com \
    --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 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.