kmalloc memory slower than malloc

Thommy Jakobsson thommyj at gmail.com
Fri Sep 6 05:36:07 EDT 2013



On Fri, 6 Sep 2013, Lucas Stach wrote:

> > static int device_mmap(struct file *filp, struct vm_area_struct *vma)
> >  {
> > 	unsigned long size;
> > 	int res = 0;
> > 	size = vma->vm_end - vma->vm_start;
> > 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > 
> 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.
Well that explains it, you think that calling a function named noncached 
would have be a tell, but apparently no =). Thanks Lucas for spotting 
that. I should not copy and paste so much I guess.

> Before doing so read up on how conflicting page mappings can lead to
> undefined behavior on ARMv7 systems and consider the consequences
> carefully. If you aren't sure you understood the problem fully and know
> how to mitigate the problems, back out and live with an uncached or
> writecombined mapping.
I have read up a bit on it, but isn't so that I have conflicting page 
mappings now in my test? Since the kernel is accessing the buffer as 
cached and userspace as noncached? If I would use cached in both places I 
assume that I wouldn't have conflicting page mappings?

Thanks,
Thommy



More information about the linux-arm-kernel mailing list