libhybris & mali400, high cpu usage investigation

gistfile1.txt

Trying to find a culprit to blame for the sched_yield() calls logged at
    https://gist.github.com/ssvb/5492148

# gdb ./test_glesv2

[...]

linker.c:661| WARNING: `libc.so` is not a prelinked library
    0 mapped library 'libc.so' to b6d0a000 via kernel allocator.

linker.c:661| WARNING: `libMali.so` is not a prelinked library
    0 mapped library 'libMali.so' to b6ae0000 via kernel allocator.

[...]

Setting breakpoint on a 'sched_yield' syscall.

(gdb) b *0xb6d17804
Breakpoint 1 at 0xb6d17804

Breakpoint 1, 0xb6d17804 in ?? ()
(gdb) bt
#0  0xb6d17804 in ?? ()
#1  0xb6ae8de0 in ?? ()
#2  0xb6ae8de0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x/100a $sp
0xbeffef98:	0x371f8	0x1	0x371f8	0x0
0xbeffefa8:	0x1	0x17f50	0x371f8	0xb6b25ca0
0xbeffefb8:	0x371f8	0xb6b25e0c	0x17a10	0xb6bceff0
0xbeffefc8:	0x0	0xb6b2fbb4	0xb6bceff4	0xb6bceff0
0xbeffefd8:	0x0	0x0	0x0	0x0
0xbeffefe8:	0xb6bceff4	0x39890	0x381b0	0x12098 <offset_x>
0xbeffeff8:	0x1	0x38128	0x120b4 <offset_loc>	0x120b8 <phase_loc>
0xbefff008:	0x96e0 <vertexArray>	0xb6b3d130	0x39890	0xb6af9af0
0xbefff018:	0x381b0	0x4000	0x12098 <offset_x>	0xb6af3008
0xbefff028:	0x1	0xb6b2fbb4	0x18830	0x18834
0xbefff038:	0x1	0xb6d780fa	0xbefff05c	0x0
0xbefff048:	0xb6d780fa	0xb6d652cd	0xb6d7d154	0xb6d655eb
0xbefff058:	0x401be76c	0x3f000000	0xffffffff	0xb6d66529
0xbefff068:	0xbefff098	0xb6d7d154	0x38128	0x401be76c
0xbefff078:	0x3f000000	0x0	0x0	0x381b0
0xbefff088:	0x4000	0x12098 <offset_x>	0x1	0x38128
0xbefff098:	0x120b4 <offset_loc>	0x120b8 <phase_loc>	0x96e0 <vertexArray>	0xb6aeb98c
0xbefff0a8:	0xb6f0d03c	0x4000	0x12098 <offset_x>	0xb6effac8
0xbefff0b8:	0xb6d7d154	0x6ea	0x120b0 <position_loc>	0x8f40 <main+516>
0xbefff0c8:	0x0	0x96e0 <vertexArray>	0x60000011	0x1
0xbefff0d8:	0x3098	0x2	0x3038	0x3020
0xbefff0e8:	0x20	0x3040	0x4	0x3038
0xbefff0f8:	0xb6ffb4c8	0x0	0x0	0x0
0xbefff108:	0x0	0x910c <_start>	0x0	0x0
0xbefff118:	0x0	0xb6ffefb0	0x0	0xb6daddf8
(gdb) disassemble 0xb6d177f0, +100
Dump of assembler code from 0xb6d177f0 to 0xb6d17854:
   0xb6d177f0:	bxpl	lr
   0xb6d177f4:	b	0xb6d43c58
   0xb6d177f8:	push	{r4, r7}
   0xb6d177fc:	mov	r7, #158	; 0x9e
   0xb6d17800:	svc	0x00000000
=> 0xb6d17804:	pop	{r4, r7}
   0xb6d17808:	movs	r0, r0
   0xb6d1780c:	bxpl	lr
   0xb6d17810:	b	0xb6d43c58
   0xb6d17814:	push	{r4, r7}
   0xb6d17818:	mov	r7, #154	; 0x9a
   0xb6d1781c:	svc	0x00000000
   0xb6d17820:	pop	{r4, r7}
   0xb6d17824:	movs	r0, r0
   0xb6d17828:	bxpl	lr
   0xb6d1782c:	b	0xb6d43c58
   0xb6d17830:	push	{r4, r7}
   0xb6d17834:	mov	r7, #155	; 0x9b
   0xb6d17838:	svc	0x00000000
   0xb6d1783c:	pop	{r4, r7}
   0xb6d17840:	movs	r0, r0
   0xb6d17844:	bxpl	lr
   0xb6d17848:	b	0xb6d43c58
   0xb6d1784c:	push	{r4, r7}
   0xb6d17850:	mov	r7, #159	; 0x9f
End of assembler dump.

# readelf -s libMali.so | grep yield
    16: 00000000     0 FUNC    GLOBAL DEFAULT  UND sched_yield

These CPU eating 'sched_yield' syscalls are apparently originating from
the libMali.so blob.


As an additional observation, commenting out FBIO_WAITFORVSYNC ioctl in 
"openbox/device/allwinner/common/gralloc/framebuffer_device.cpp"
(compiled to gralloc.sun4i.so) drops CPU usage to ~0% in test_glesv2
application, but naturally runs too fast and introduces tearing.