linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: l.stach@pengutronix.de (Lucas Stach)
To: linux-arm-kernel@lists.infradead.org
Subject: kmalloc memory slower than malloc
Date: Tue, 10 Sep 2013 12:10:16 +0200	[thread overview]
Message-ID: <1378807816.4200.6.camel@weser.hi.pengutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1309101124450.1305@kelly.ryd.net>

Am Dienstag, den 10.09.2013, 11:54 +0200 schrieb Thommy Jakobsson:
> 
> On Fri, 6 Sep 2013, Lucas Stach wrote:
> 
> > This is the relevant part where you are mapping things uncached into
> > userspace, so no wonder it is slower than cached malloc memory. If you
> > want to use cached userspace mappings you need bracketed MMAP access,
> > where you tell the kernel by using an ioctl or something that userspace
> > is accessing the mapping so it can flush/invalidate caches at the right
> > points in time.
> Removing the pgprot_noncached() seems to make things more what I expected. 
> Both buffers takes about the same time to traverse in userspace. Thanks.
> 
> I changed the code in my testprogram and driver to do the same thing in 
> kernelspace as well. And now I don't understand the result. The result 
> stepping through and adding all bytes in a page sized buffer is about 4-5 
> times faster to do in the kernel. This is the times for looping through 
> the buffer 10000 times on a imx6:
> dma_alloc_coherent in kernel   4.256s (s=0)
> kmalloc in kernel              0.126s (s=86700000)
> dma_alloc_coherent userspace   0.566s (s=0)
> kmalloc in userspace          0.566s (s=86700000)
> malloc in userspace          0.566s (s=0)
> 
How do you init the kmalloc memory? If you do a memset right before the
test loop your "kmalloc in kernel" will most likely always hit in the L1
cache, that's why it's really fast to do.

The userspace mapping of the kmalloc memory will get a different virtual
address than the kernel mapping. So if you do a memset in kernelspace,
but the test loop in userspace you'll always miss the cache as the ARM
v7 caches are virtually indexed. So the processor always fetches data
from memory. The performance advantage against an uncached mapping is
entirely due to the fact that you are fetching whole cache lines
(32bytes) from memory at once, instead of doing a memory/bus transaction
per byte.

Regards,
Lucas
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2013-09-10 10:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06  7:48 kmalloc memory slower than malloc Thommy Jakobsson
2013-09-06  8:07 ` Russell King - ARM Linux
2013-09-06  9:04   ` Thommy Jakobsson
2013-09-06  9:12 ` Lucas Stach
2013-09-06  9:36   ` Thommy Jakobsson
2013-09-10  9:54   ` Thommy Jakobsson
2013-09-10 10:10     ` Lucas Stach [this message]
2013-09-10 10:42       ` Duan Fugang-B38611
2013-09-10 11:28         ` Thommy Jakobsson
2013-09-10 11:36           ` Duan Fugang-B38611
2013-09-10 11:44             ` Russell King - ARM Linux
2013-09-10 12:42               ` Thommy Jakobsson
2013-09-10 12:50                 ` Russell King - ARM Linux
2013-09-12 15:58                   ` Thommy Jakobsson
2013-09-12 16:19                     ` Russell King - ARM Linux
2013-09-10 11:27       ` Thommy Jakobsson
2013-09-10 11:41     ` Russell King - ARM Linux
2013-09-10 12:54       ` Thommy Jakobsson

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=1378807816.4200.6.camel@weser.hi.pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.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).