Cortex-A8处理器memcpy的优化方案

公司产品涉及到视频编解码和人脸识别,但是出现帧率太低的现象,同事做了一些测试,最后问题定位到应用程序中memcpy慢,特别是由uncached区域(视频采集buf,使用mmap对/dev/mem映射到用户空间)到cached区域(用户空间malloc),因此需要想办法进行下优化。
首先交代下设备处理器背景,处理器是公司自研,使用ARM Cortex-A8处理器核,CPU为800MHZ,SAXI总线为533MHZ。后续一系列测试都是在相同的clk下进行,保证测试数据的硬件环境一致,有可对比性。
同事对系统下各种场景的memcpy进行一系列测试。测试数据如下。
这里写图片描述
对这个表的测试方法进行下说明,kernel和user空间下分别使用do_gettimeofday和gettimeofday获取时间,公司SOC的地址空间中0x80000000开始是ddr空间,kernel的cmdline中mem=256MB,因此0x80000000-0x90000000为lowmem。
mmap映射/dev/mem可以完成整个4G空间的映射(关于mem驱动的原理,可以看我的另一篇学习powerpc /dev/mem的博文,http://blog.csdn.net/skyflying2012/article/details/47611399),但是具体访问权限以及属性还需要看mem驱动中mmap函数的实现。
公司设备的应用场景是从物理地址0x90000000的uncached区域到cached区域进行memcpy,测试速度仅有11MB/s,这对于1080P的人脸识别完全不够,优化是必须的。
仔细对比分析这组测试数据,我有以下几个疑问。
1 用户空间mmap mem的uncached区域(mem驱动中映射页表属性默认是uncached)向malloc出来的cached缓冲区拷贝,0x80000000区域为什么比0x90000000区域的拷贝快?
2 kernel下ioremap的uncached区域向kmalloc的cached区域拷贝,为什么比用户空间的快很多?
3 kmalloc的cached区域向ioremap的uncached区域拷贝,为什么比kernel下ioremap的uncached区域向kmalloc的cached区域拷贝要慢很多?
3个问题逐步递进,都分析明白解决了,特别是第2点,内核memcpy远快于用户空间,就能找到一些对用户空间memcpy的优化方法。

那我们就来逐步的分析下这3个问题。

1 用户空间mmap mem的uncached区域向malloc出来的cached缓冲区拷贝,0x80000000区域为什么比0x90000000区域的拷贝快?

这2者都是在用户空间进行测试,测试代码完全一致,统计方法也都一致,memcpy都是使用的libc库的实现。为什么memcpy速度不一样,想来想去也只有可能是这2个区域的页表属性不一样,有可能一个cached一个uncached,这个需要从mem驱动的实现下手。
公司kernel版本是3.4.55。mem实现在kernel的driver/char/mem.c中,找到mem的mmap实现,如下

static int mmap_mem(struct file *file, struct vm_area_struct *vma)
{
    size_t size = vma->vm_end - vma->vm_start;

    if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
        return -EINVAL;

    if (!private_mapping_ok(vma))
        return -ENOSYS;

    if (!range_is_allowed(vma->vm_pgoff, size))
        return -EPERM;

    if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size,
                        &vma->vm_page_prot))
        return -EINVAL;

    vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff,
                         size,
                         vma->vm_page_prot);

    /* Remap-pfn-range will mark the range VM_IO and VM_RESERVED */
    if (remap_pfn_range(vma,
                vma->vm_start,
                vma->vm_pgoff,
                size,
                vma->vm_page_prot)) {
        return -EAGAIN;
    }
    return 0;
}

mmap_mem开始会进行映射区域的一些检查,然后设置映射属性,最后调用remap_pfn_range建立真正的页表。我们所关心的是映射属性,就是phys_mem_access_prot的实现。该函数在mem.c中有一个实现,对于ARM架构来说,phys_mem_access_prot默认设置属性位uncached。
但是由于公司设备在menuconfig时定义了CONFIG_ARM_DMA_MEM_BUFFERABLE(该选项使DMA一致性映射时属性为bufferable而不是uncached,但是发现一致性映射工作正常,很奇怪为什么选这个),phys_mem_access_prot的实现在arch/arm/mm/mmu.c中,如下。

#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
                  unsigned long size, pgprot_t vma_prot)
{
    if (!pfn_valid(pfn))
    {
        return pgprot_noncached(vma_prot);
    }
    else if (file->f_flags & O_SYNC)
    {
        return pgprot_writecombine(vma_prot);
    }
    return vma_prot;
}
EXPORT_SYMBOL(phys_mem_access_prot);
#endif

应用程序测试代码中mem设备open时设置了属性O_SYNC,因此主要看pfn_valid实现了,看字面意思,该pfn页有效,则属性为bufferable,反之为uncached。pfn_valid在arch/arm/mm/init.c中,如下。

#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
    return memblock_is_memory(__pfn_to_phys(pfn));
}
EXPORT_SYMBOL(pfn_valid);

memblock_is_memory实现在/mm/memblock.c中,该函数实现这里不详细说了,后续在我的内存管理学习笔记专栏里会详细学习。
这里简单说明下,memblock.c中维护了memblock.memory(可用)和memblock.reserve(保留)2个链表,arm-linux启动中,在paging_init建立页表前,会调用arm_memblock_init对memblock链表进行初始化,arm_memblock_init中会将cmdline中指定的lowmem调用memblock_add添加到memblock.memory链表中(公司kernel没有配置CONFIG_HIGHMEM)。
而memblock_is_memory是在memblock.memory链表中搜索是否有该物理页。
因此pfn_valid对于lowmem(0x80000000-0x90000000)返回ture,对于其他物理地址则返回false。
返回上级函数phys_mem_access_prot,一目了然,该函数的逻辑是对于mmap映射lowmem(0x80000000-0x90000000)区域,页表映射属性prot配置为bufferable,其他区域页表属性配置为uncached。
这样第一个问题就解决了,对于公司设备的kernel,用户空间mmap mem驱动,物理地址在0x80000000-0x90000000区域内,为bufferable,其他区域为uncached(这样reg空间也可以映射出来访问,实现用户空间驱动)。所以映射lowmem区域的拷贝速度要快于其他区域。
不过要说明下的是,这个问题是因为该kernel配置了CONFIG_ARM_DMA_MEM_BUFFERABLE,使用了arm特定的phys_mem_access_prot实现。
如果不配置该选项,则mmap_mem使用了mem.c中的phys_mem_access_prot实现。该实现中如果open时指定了O_SYNC或者O_DSYNC,则所有空间的映射属性都配置为uncached。

2 kernel下ioremap的uncached区域向kmalloc的cached区域拷贝,为什么比用户空间uncached到cached区域拷贝要快很多?

这个问题如果解决,对于优化用户空间memcpy会很有帮助,对于同事测试的数据,我从以下3个方面进行了分析调试。
(1)统计时间的准确性不一致,需要修改。
kernel下使用do_gettimeofday获取时间,kernel下是没有调度的(进程调度发生在由内核态返回时,检查是否有就绪进程,然后调度。内核态下即使发生中断,都还只是内核态下的相互切换,不会有调度),但是用户空间有进程调度(中断 系统调用等异常,导致陷入内核态,再返回时产生调度),进程调度对时间统计准确性有影响,一是会导致gettimeofday时间统计没有内核态下那么准确(有部分时间是其他进程的开销),二是进程调度还需要切换进程的页表(每个进程独立拥有16KB内存页表),进程调度导致页表切换,MMU需要重新读入TLB,我想也会对性能有所影响吧。
因此要想办法统一时间统计方法,使应用程序暂时不再调度。我的解决方法如下。
a 保证应用程序不产生调度
在应用程序中将处理器的寄存器空间mmap出来,在开始测试前配置中断寄存器将中断全部mask,测试结束再unmask,保证没有中断产生而陷入内核态,
再对malloc区域提前访问,保证页表提前建立,不会产生缺页异常(malloc缓冲区在访问时才缺页异常建立页表)。
不使用gettimeofday系统调用,二是直接读取timer计数,利用计数来计算用时。
b 对于内核测试代码,也不使用do_gettimeofday,直接读取timer计数,计算用时,与应用程序统一。
对应用程序进行修改后,再次测试1MB数据从uncached区域到cached区域拷贝,计算用时是68ms,速度为14.7MB/s。相比于同事的测试数据的确有所提升,这说明用户空间进程调度对时间统计是有些影响,但是排除进程调度影响后的测试速度跟内核的速度还是相差很大。看来根本原因还没有找到。

(2)memcpy实现不一致。
kernel不依赖于任何库,自己实现memcpy,应用程序的memcpy是依赖于libc中的实现,这2者实现可能有差异。
这个的解决方法就简单粗暴了,对比memcpy的实现呗。
kernel的memcpy实现在arch/arm/lib/memcpy.S中,是汇编代码,粗略看了下实现。
主要是使用PLD指令(armv5以上支持)进行数据预取,并且使用stmia/ldmia进行数据的32 bytes批量读写。
而对于应用程序的memcpy实现,如果去找libc的实现,要麻烦些,需要顺着所使用的编译器一步步的找相应的版本,
这里想了一个懒办法。就是将应用程序静态编译,然后反汇编找memcpy实现,在反汇编文件中找到memcpy实现,如下:

00014104 <memcpy>:
   14104:   e3520003    cmp r2, #3  ; 0x3
   14108:   e92d07f0    push    {r4, r5, r6, r7, r8, r9, sl}
   1410c:   8a000009    bhi 14138 <memcpy+0x34>
   14110:   e3520000    cmp r2, #0  ; 0x0
   14114:   0a000005    beq 14130 <memcpy+0x2c>
   14118:   e3a0c000    mov ip, #0  ; 0x0
   1411c:   e7d1300c    ldrb    r3, [r1, ip]
   14120:   e7c0300c    strb    r3, [r0, ip]
   14124:   e28cc001    add ip, ip, #1  ; 0x1
   14128:   e152000c    cmp r2, ip
   1412c:   8afffffa    bhi 1411c <memcpy+0x18>
   14130:   e8bd07f0    pop {r4, r5, r6, r7, r8, r9, sl}
   14134:   e12fff1e    bx  lr
   14138:   e3100003    tst r0, #3  ; 0x3
   1413c:   e0809002    add r9, r0, r2
   14140:   01a0c000    moveq   ip, r0
   14144:   01a04001    moveq   r4, r1
   14148:   0a000005    beq 14164 <memcpy+0x60>
   1414c:   e1a0c000    mov ip, r0
   14150:   e4d13001    ldrb    r3, [r1], #1
   14154:   e4cc3001    strb    r3, [ip], #1
   14158:   e31c0003    tst ip, #3  ; 0x3
   1415c:   1afffffb    bne 14150 <memcpy+0x4c>
   14160:   e1a04001    mov r4, r1
   14164:   e2117003    ands    r7, r1, #3  ; 0x3
   14168:   0a00001c    beq 141e0 <memcpy+0xdc>
   1416c:   e06ca009    rsb sl, ip, r9
   14170:   e2672000    rsb r2, r7, #0  ; 0x0
   14174:   e35a0003    cmp sl, #3  ; 0x3
   14178:   e7916002    ldr r6, [r1, r2]
   1417c:   da00000d    ble 141b8 <memcpy+0xb4>
   14180:   e2673004    rsb r3, r7, #4  ; 0x4
   14184:   e0815002    add r5, r1, r2
   14188:   e1a08183    lsl r8, r3, #3
   1418c:   e1a0100a    mov r1, sl
   14190:   e1a07187    lsl r7, r7, #3
   14194:   e5b52004    ldr r2, [r5, #4]!
   14198:   e2411004    sub r1, r1, #4  ; 0x4
   1419c:   e1a03812    lsl r3, r2, r8
   141a0:   e1833736    orr r3, r3, r6, lsr r7
   141a4:   e3510003    cmp r1, #3  ; 0x3
   141a8:   e48c3004    str r3, [ip], #4
   141ac:   e2844004    add r4, r4, #4  ; 0x4
   141b0:   e1a06002    mov r6, r2
   141b4:   cafffff6    bgt 14194 <memcpy+0x90>
   141b8:   e159000c    cmp r9, ip
   141bc:   83a02000    movhi   r2, #0  ; 0x0
   141c0:   9affffda    bls 14130 <memcpy+0x2c>
   141c4:   e7d43002    ldrb    r3, [r4, r2]
   141c8:   e7cc3002    strb    r3, [ip, r2]
   141cc:   e2822001    add r2, r2, #1  ; 0x1
   141d0:   e08c3002    add r3, ip, r2
   141d4:   e1590003    cmp r9, r3
   141d8:   8afffff9    bhi 141c4 <memcpy+0xc0>
   141dc:   eaffffd3    b   14130 <memcpy+0x2c>
   141e0:   e06c6009    rsb r6, ip, r9
   141e4:   e356003f    cmp r6, #63 ; 0x3f
   141e8:   da000026    ble 14288 <memcpy+0x184>
   141ec:   e1a05006    mov r5, r6
   141f0:   e5943000    ldr r3, [r4]
   141f4:   e2455040    sub r5, r5, #64 ; 0x40
   141f8:   e58c3000    str r3, [ip]
   141fc:   e5942004    ldr r2, [r4, #4]
   14200:   e355003f    cmp r5, #63 ; 0x3f
   14204:   e58c2004    str r2, [ip, #4]
   14208:   e5941008    ldr r1, [r4, #8]
   1420c:   e1a06005    mov r6, r5
   14210:   e58c1008    str r1, [ip, #8]
   14214:   e594300c    ldr r3, [r4, #12]
   14218:   e58c300c    str r3, [ip, #12]
   1421c:   e5942010    ldr r2, [r4, #16]
   14220:   e58c2010    str r2, [ip, #16]
   14224:   e5943014    ldr r3, [r4, #20]
   14228:   e58c3014    str r3, [ip, #20]
   1422c:   e5942018    ldr r2, [r4, #24]
   14230:   e58c2018    str r2, [ip, #24]
   14234:   e594301c    ldr r3, [r4, #28]
   14238:   e58c301c    str r3, [ip, #28]
   1423c:   e5942020    ldr r2, [r4, #32]
   14240:   e58c2020    str r2, [ip, #32]
   14244:   e5943024    ldr r3, [r4, #36]
   14248:   e58c3024    str r3, [ip, #36]
   1424c:   e5942028    ldr r2, [r4, #40]
   14250:   e58c2028    str r2, [ip, #40]
   14254:   e594302c    ldr r3, [r4, #44]
   14258:   e58c302c    str r3, [ip, #44]
   1425c:   e5942030    ldr r2, [r4, #48]
   14260:   e58c2030    str r2, [ip, #48]
   14264:   e5943034    ldr r3, [r4, #52]
   14268:   e58c3034    str r3, [ip, #52]
   1426c:   e5942038    ldr r2, [r4, #56]
   14270:   e58c2038    str r2, [ip, #56]
   14274:   e594303c    ldr r3, [r4, #60]
   14278:   e2844040    add r4, r4, #64 ; 0x40
   1427c:   e58c303c    str r3, [ip, #60]
   14280:   e28cc040    add ip, ip, #64 ; 0x40
   14284:   caffffd9    bgt 141f0 <memcpy+0xec>
   14288:   e356000f    cmp r6, #15 ; 0xf
   1428c:   da00000e    ble 142cc <memcpy+0x1c8>
   14290:   e06c1009    rsb r1, ip, r9
   14294:   e5943000    ldr r3, [r4]
   14298:   e2411010    sub r1, r1, #16 ; 0x10
   1429c:   e58c3000    str r3, [ip]
   142a0:   e5942004    ldr r2, [r4, #4]
   142a4:   e351000f    cmp r1, #15 ; 0xf
   142a8:   e58c2004    str r2, [ip, #4]
   142ac:   e5943008    ldr r3, [r4, #8]
   142b0:   e1a06001    mov r6, r1
   142b4:   e58c3008    str r3, [ip, #8]
   142b8:   e594200c    ldr r2, [r4, #12]
   142bc:   e2844010    add r4, r4, #16 ; 0x10
   142c0:   e58c200c    str r2, [ip, #12]
   142c4:   e28cc010    add ip, ip, #16 ; 0x10
   142c8:   cafffff1    bgt 14294 <memcpy+0x190>
   142cc:   e3560003    cmp r6, #3  ; 0x3
   142d0:   daffffb8    ble 141b8 <memcpy+0xb4>
   142d4:   e06c2009    rsb r2, ip, r9
   142d8:   e2422004    sub r2, r2, #4  ; 0x4
   142dc:   e4943004    ldr r3, [r4], #4
   142e0:   e3520003    cmp r2, #3  ; 0x3
   142e4:   e48c3004    str r3, [ip], #4
   142e8:   cafffffa    bgt 142d8 <memcpy+0x1d4>
   142ec:   eaffffb1    b   141b8 <memcpy+0xb4>

libc中的memcpy实现中循环批量的使用ldr/str指令进行一次4bytes的数据读写。这么看来的确是不如kernel下的memcpy更加高效。那就想办法将kernel下的memcpy应用在用户程序中。
为了首先验证下kernel下的memcpy是否能提高应用程序的拷贝速度,直接将kernel下编译生成的memcpy.o与我的应用程序静态链接,为了确保的确是链接了memcpy.o中的memcpy,而不是libc库的。将静态链接的程序反汇编进行检查,的确是使用的memcpy.o中的memcpy实现。然后进行对比拷贝测试,结果如下。
这里写图片描述
可以看出,对于有uncache区域参与的memcpy,拷贝速度提高1倍左右。
但是对于cached到cached区域的memcpy,仅仅提升15%左右。
这说明PLD预取对拷贝影响更大,cached区域相互拷贝,cache控制器会预取cache line(32bytes)进来,因此再使用PLD预取不会再起很大作用,而仅仅是stmia/ldmia指令相较于str/ldr指令速度再略有提升。
我的理解,可以粗略估计,uncached区域性能提升1倍,PLD预取起了85%的效果,stmia/ldmia起了15%效果。
不管怎么说,总算是找到了memcpy这个可以优化的点了。

(3)页表映射的属性是否一致。
能影响访问速度的页表属性我所知道的只有cached/uncached。我的理解不管内核还是用户空间,从uncached到cached拷贝,只要是页表建立,属性确定,那么访问速度就应该是一样的。如果还不一样,看来是有别的页表属性对访问速度有影响?
即使使用kernel的memcpy,应用程序的拷贝还是比kernel的慢一些,现在能想到的不一致因素都已经保证一致了,也只有考虑页表的属性了。对于这个问题的解决,还是结合第三个疑问来一起分析。

3 kmalloc的cached区域向ioremap的uncached区域拷贝,为什么比kernel下ioremap的uncached区域向kmalloc的cached区域拷贝要慢很多?

这个问题其实是一个数据流方向问题,根据同事的测试数据可以看出,从uncached区域读取比向uncached区域写入的拷贝要慢很多。那就直接测试下uncached区域的读写。
为了保证读写的可比性 透明性,都是用嵌入式汇编编写。
读取测试代码如下。

  asm(
                "mov r0, %0\n"
                "add r1, r0, #0x100000\n"
                "1: ldr r2, [r0], #4\n"
                "cmp r0, r1\n"
                "bne 1b\n"
                :
                :"r"(addr_nc)
                :"r0", "r1", "r2"
           );

写入测试代码如下。

asm(
                "mov r0, %0\n"
                "add r1, r0, #0x100000\n"
                "ldr r3, =0x12345678\n"
                "2: str r3, [r0], #4\n"
                "cmp r0, r1\n"
                "bne 2b\n"
                :
                :"r"(addr_nc)
                :"r0", "r1", "r3"
           );

将应用程序编译后再反汇编查看,保证对于循环的读写没有进行优化。
测试发现,写入1MB数据使用4.7ms,读取1MB数据使用36.8ms。相差了近8倍!。
在uboot以及应用程序中也加入该汇编代码进行测试,并且让IC验证工程师对读写汇编代码进行了FPGA仿真,将memcpy测试数据加进来,测试结果如下。
这里写图片描述
uboot和FPGA下关闭了dcached,因此没有测试cached操作数据。
可以看出cached区域内的拷贝读写,kernel app都是一致的,但是uncached参与的拷贝读写kernel跟uboot app就有差别了。uboot app中的读写速度跟FPGA仿真接近。
IC工程师在查看仿真波形后,解释说读比写多出来的时间是CPU内部的时间,而不是总线上的时间。这也就说明FPGA仿真出来,读比写慢30%是Cortex-A8处理器核的问题。这个不是软件上能解决的了。
根据测试数据表,可以看出kernel下的memcpy快跟uncached写快是有关系的。
实在没有别的办法,只能将用户空间映射的uncached区域和kernel下映射的uncached区域的页表属性都打印出来进行对比。
对于用户空间映射的页表属性,在/driver/char/mem.c的mmap_mem中加在phys_mem_access_prot之后,将vma->vm_page_prot打印出来。值为0x103
对于内核空间映射的页表属性,内核模块使用ioremap映射的uncached区域,在ioremap中的__arm_ioremap_pfn_caller中将type->prot_pte打印出来。值为0x653
这个prot值是linux页表的属性值,这里需要知道的是linux为了保证兼容性,分别建立了linux二级页表和硬件二级页表,各占2KB,一起占用4KB一个页。这里的原理在我的内存管理学习笔记再详细说明。
linux二级页表是供linux系统进行页表管理,而硬件二级页表则是供处理器MMU进行读取。
linux二级页表的位定义在/arch/arm/include/asm/pgtable-2level.h中,如下。

/*
 * "Linux" PTE definitions.
 *
 * We keep two sets of PTEs - the hardware and the linux version.
 * This allows greater flexibility in the way we map the Linux bits
 * onto the hardware tables, and allows us to have YOUNG and DIRTY
 * bits.
 *
 * The PTE table pointer refers to the hardware entries; the "Linux"
 * entries are stored 1024 bytes below.
 */
#define L_PTE_PRESENT       (_AT(pteval_t, 1) << 0)
#define L_PTE_YOUNG     (_AT(pteval_t, 1) << 1)
#define L_PTE_FILE      (_AT(pteval_t, 1) << 2) /* only when !PRESENT */
#define L_PTE_DIRTY     (_AT(pteval_t, 1) << 6)
#define L_PTE_RDONLY        (_AT(pteval_t, 1) << 7)
#define L_PTE_USER      (_AT(pteval_t, 1) << 8)
#define L_PTE_XN        (_AT(pteval_t, 1) << 9)
#define L_PTE_SHARED        (_AT(pteval_t, 1) << 10)    /* shared(v6), coherent(xsc3) */

/*
 * These are the memory types, defined to be compatible with
 * pre-ARMv6 CPUs cacheable and bufferable bits:   XXCB
 */
#define L_PTE_MT_UNCACHED   (_AT(pteval_t, 0x00) << 2)  /* 0000 */
#define L_PTE_MT_BUFFERABLE (_AT(pteval_t, 0x01) << 2)  /* 0001 */
#define L_PTE_MT_WRITETHROUGH   (_AT(pteval_t, 0x02) << 2)  /* 0010 */
#define L_PTE_MT_WRITEBACK  (_AT(pteval_t, 0x03) << 2)  /* 0011 */
#define L_PTE_MT_MINICACHE  (_AT(pteval_t, 0x06) << 2)  /* 0110 (sa1100, xscale) */
#define L_PTE_MT_WRITEALLOC (_AT(pteval_t, 0x07) << 2)  /* 0111 */
#define L_PTE_MT_DEV_SHARED (_AT(pteval_t, 0x04) << 2)  /* 0100 */
#define L_PTE_MT_DEV_NONSHARED  (_AT(pteval_t, 0x0c) << 2)  /* 1100 */
#define L_PTE_MT_DEV_WC     (_AT(pteval_t, 0x09) << 2)  /* 1001 */
#define L_PTE_MT_DEV_CACHED (_AT(pteval_t, 0x0b) << 2)  /* 1011 */
#define L_PTE_MT_MASK       (_AT(pteval_t, 0x0f) << 2)

根据linux页表的位定义,0x653和0x103都是配置为uncached,其他位看字面含义也不会对uncached写入速度有影响。
只能采取测试的方法,将页表属性中配置有差别的置位在mem.c中的mmap_mem函数中进行测试。
我在mem.c中建立sys文件入口prot,可以在应用中动态修改mem驱动中的prot值,一位一位的修改,测试哪一位会对uncached写入速度有影响。
测试中果然发现,在置位L_PTE_MT_DEV_SHARED也就是bit4后,mmap /dev/mem的uncached区域的写入以及拷贝速度瞬间提升,uncached区域写入1MB数据耗时4.8ms,跟kernel下的测试接近!
ioremap以及mmap中计算的prot属性值是填写在linux软件页表中,如果要搞清楚L_PTE_MT_DEV_SHARED位为什么会影响写入速度,我们需要搞清楚L_PTE_MT_DEV_SHARED位对应于硬件页表是哪一位,以及硬件页表中该位是起了什么作用。

公司处理器是armV7架构,使用两级页表。不管上层调用如何进行软件操作,硬件页表的填写是在linux最底层页表配置函数cpu_v7_set_pte_ext中。其中会首先配置linux软件二级页表,然后根据linux二级页表的位定义来配置相应的硬件页表。
该函数是arch/arm/mm/proc-v7-2level.S中,如下

/*
 *  cpu_v7_set_pte_ext(ptep, pte)
 *
 *  Set a level 2 translation table entry.
 *
 *  - ptep  - pointer to level 2 translation table entry
 *        (hardware version is stored at +2048 bytes)
 *  - pte   - PTE value to store
 *  - ext   - value for extended PTE bits
 */
ENTRY(cpu_v7_set_pte_ext)
#ifdef CONFIG_MMU
    str r1, [r0]            @ linux version

    bic r3, r1, #0x000003f0
    bic r3, r3, #PTE_TYPE_MASK
    orr r3, r3, r2
    orr r3, r3, #PTE_EXT_AP0 | 2

    tst r1, #1 << 4
    orrne   r3, r3, #PTE_EXT_TEX(1)

    eor r1, r1, #L_PTE_DIRTY
    tst r1, #L_PTE_RDONLY | L_PTE_DIRTY
    orrne   r3, r3, #PTE_EXT_APX

    tst r1, #L_PTE_USER
    orrne   r3, r3, #PTE_EXT_AP1
#ifdef CONFIG_CPU_USE_DOMAINS
    @ allow kernel read/write access to read-only user pages
    tstne   r3, #PTE_EXT_APX
    bicne   r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
#endif

    tst r1, #L_PTE_XN
    orrne   r3, r3, #PTE_EXT_XN

    tst r1, #L_PTE_YOUNG
    tstne   r1, #L_PTE_PRESENT
    moveq   r3, #0

 ARM(   str r3, [r0, #2048]! )
 THUMB( add r0, r0, #2048 )
 THUMB( str r3, [r0] )
    mcr p15, 0, r0, c7, c10, 1      @ flush_pte
#endif
    mov pc, lr
ENDPROC(cpu_v7_set_pte_ext)

该汇编函数首先将linux软件页表(r1参数1即为软件页表值)存入低2KB页内,然后根据软件页表值来配置硬件页表值,最后将硬件页表值写入高2KB内。
其中使用的硬件二级页表位定义在/arch/arm/include/asm/pgtable-2level-hwdef.h中,如下。

/*
 * + Level 2 descriptor (PTE)
 *   - common
 */
#define PTE_TYPE_MASK       (_AT(pteval_t, 3) << 0)
#define PTE_TYPE_FAULT      (_AT(pteval_t, 0) << 0)
#define PTE_TYPE_LARGE      (_AT(pteval_t, 1) << 0)
#define PTE_TYPE_SMALL      (_AT(pteval_t, 2) << 0)
#define PTE_TYPE_EXT        (_AT(pteval_t, 3) << 0)     /* v5 */
#define PTE_BUFFERABLE      (_AT(pteval_t, 1) << 2)
#define PTE_CACHEABLE       (_AT(pteval_t, 1) << 3)

/*
 *   - extended small page/tiny page
 */
#define PTE_EXT_XN      (_AT(pteval_t, 1) << 0)     /* v6 */
#define PTE_EXT_AP_MASK     (_AT(pteval_t, 3) << 4)
#define PTE_EXT_AP0     (_AT(pteval_t, 1) << 4)
#define PTE_EXT_AP1     (_AT(pteval_t, 2) << 4)
#define PTE_EXT_AP_UNO_SRO  (_AT(pteval_t, 0) << 4)
#define PTE_EXT_AP_UNO_SRW  (PTE_EXT_AP0)
#define PTE_EXT_AP_URO_SRW  (PTE_EXT_AP1)
#define PTE_EXT_AP_URW_SRW  (PTE_EXT_AP1|PTE_EXT_AP0)
#define PTE_EXT_TEX(x)      (_AT(pteval_t, (x)) << 6)   /* v5 */
#define PTE_EXT_APX     (_AT(pteval_t, 1) << 9)     /* v6 */
#define PTE_EXT_COHERENT    (_AT(pteval_t, 1) << 9)     /* XScale3 */
#define PTE_EXT_SHARED      (_AT(pteval_t, 1) << 10)    /* v6 */
#define PTE_EXT_NG      (_AT(pteval_t, 1) << 11)    /* v6 */

cpu_v7_set_pte_ext中根据软件页表的bit4来配置硬件页表的代码如下。

    tst r1, #1 << 4
    orrne   r3, r3, #PTE_EXT_TEX(1)

如果软件页表中置位bit4,则硬件页表中置位bit6。也就是说硬件页表中置位bit6,使uncached的写入拷贝速度提升
那么bit6到底是干啥的呢,这涉及到armv7处理器的MMU,需要看armv7架构处理器的datasheet了。
我在arm以及armv7架构的datasheet中的确是找到了一些关于bit6的说明,如下。
4K页的二级页表未定义

映射空间属性的说明

ARM处理器核的官方datasheet下载链接如下:http://download.csdn.net/detail/skyflying2012/9530439
ARMV7架构处理器的官方datasheet下载链接如下:http://download.csdn.net/detail/skyflying2012/9530443

bit6是硬件页表的TEX[2:0]的最低位,根据上图的说明,访问区域属性的确是由TEX[2:0]以及cached/bufferable 2位一起来控制。但是我还没有找到具体的说明TEX[2:0]对读写影响的说明,后续搞明白后再来补上。
mem.c中置位L_PTE_MT_DEV_SHARED,并且链接kernel的memcpy.o,应用程序对读写拷贝进行测试,跟kernel下的测试速度基本一致了,相较于以前有了大幅提升。
到这里算是解决了我的后2个疑问了。
kernel下ioremap的uncached区域向kmalloc的cached区域拷贝比用户空间的快,原因有2个。
(1)kernel的memcpy比应用程序的效率更高
(2)kernel下建立的软件页表置位了L_PTE_MT_DEV_SHARED,对应于硬件页表的bit6,测试发现可以大幅提升uncached写入速度,从而是memcpy性能再度提升。
kmalloc的cached区域向ioremap的uncached区域拷贝,比kernel下ioremap的uncached区域向kmalloc的cached区域拷贝要慢很多,也是因为软件页表的了L_PTE_MT_DEV_SHARED位。

解决了我对测试数据的3个疑问,对于公司cortex-A8处理器memcpy的优化也就有了几点方法,如下。
(1)使用kernel的memcpy,将kernel下的memcpy抠出来,单独编译成一个库使用。(代码我后续上传到我的资源中)
(2)在mem.c驱动的mmap_mem函数中,置位L_PTE_MT_DEV_SHARED。不过由于还未搞懂其真正含义,不知其有无其他影响,该方法谨慎使用
(3)对于涉及malloc区域的memcpy,提前访问缓冲区,建立页表。该点对于提高memcpy效率有点效果,但是对于程序整体效率无作用(因为缺页异常是必须的)

最后我对采用该优化方案的memcpy进行了一组对比试验,测试拷贝1MB数据的耗时,统计时间还是采用关中断
读timer计数的方式,数据如下。
这里写图片描述
可以看出,对于有uncached区域参与的memcpy,优化后性能提升明显,
uncached->uncached提升3倍,uncached->cached提升3.5倍,cached->uncached提升13.2倍!
cached->uncached提升最多,我的理解是因为置位L_PTE_MT_DEV_SHARED对写入速度提升最为明显导致的。

但是对于cached内部的memcpy,速度提升不明显。看来置位L_PTE_MT_DEV_SHARED对cached区域无影响,而cached区域本身就有cache line的预取,因此memcpy的PLD预取也没有起作用,只有stmia/ldmia的32bytes批量操作相比与str/ldr的4bytes操作有一点性能的提升。

对于公司设备memcpy的优化记录到这里。最后需要说明的也是最重要的一点,
我的以上优化方法,都在armv7架构的cortex-a8处理器下进行的,pld预取以及硬件页表的bit6置位都需要特定处理器的支持。这都是针对Cortex-A8处理器的优化,并且对于有uncached区域参与的拷贝提升明显,cached区域内拷贝效果不是很明显。

我测试过arm9处理器的memcpy,发现arm9的读写拷贝性能都很均衡,不会出现armv7这种写比读快很多的情况,这些都是跟特定处理器的特定配置是有关系的。

因此朋友们照搬我这套优化方案,有可能是没有效果的,我这里更多的是提供给大家这一套优化的思路供选择。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页