• Locked Locked
  • Replies 8 replies
  • Subscribers 136 subscribers
  • Views 6522 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

bad performance on 3.8 kernel

Marian Mihailescu
Note: This was originally posted on 18th June 2013 at http://forums.arm.com

Mali 400 on an exynos-based board:

with 3.0 kernel, EGL working fine, with up to 600fps in es2gears

ported drivers to 3.8 kernel, and mali acceleration working, however, the performance is roughly 50%.

I have debugged the issue at the gp job start wrapper - _mali_ukk_gp_start_job, which is called now 50% more times than on the 3.0 kernel...

Here is a comparison between the 2 kernels:

1) with SKIP_GP_JOBS and retuning the job straight away from _mali_ukk_gp_start_job, both 3.0 and 3.8 kernel results in the same number of mali_ioctl calls and the same performance - 650fps in es2gears
2) i modified es2gears to stop after 600 frames and here are my results (from bottom to top):

      GP jobs actually done - calls to "mali_gp_job_start": 299 on 3.0 kernel, 302 on 3.8 kernel
      calls to mali_group_start_gp_job (which calls mali_gp_job_start): 299 on 3.0, 302 on 3.8 kernel
      executions of mali_gp_scheduler_schedule (which calls mali_group_start_gp_job): 299 on 3.0, 302 on 3.8 kernel -- appears as "mali_gp_scheduler_schedule() {" in ftrace
      calls to mali_gp_scheduler_schedule: 0 on 3.0, 299 on 3.8 kernel -- appears as "mali_gp_scheduler_schedule();" in ftrace
     
      system calls served (mali_ioctl) : 960 on 3.0 kernel, 1373 on 3.8 kernel

results: ~600fps on 3.0 kernel, ~380fps on 3.8 kernel

So the conclusion is that the slowdown is due to a much larger number (almost double) of mali_ioctls for MALI_IOC_GP2_START_JOB.

Since I don't have the code for libMali to debug why exactly it's making so many syscalls, I hope somebody here can help me and give me an idea where to look.

A strange thing is the job numbers assigned.
In the 3.0 kernel, they are all multiples of 4, like: Mali GP scheduler: Job 2405 (0xE6581B80) queued; 2409, 2413, 2417, 2421, 2425, ...
In the 3.8 kernel, they increment either by 2, 4 or 6: 8825, 8829, 8833, 8835, 8841, 8843, 8849, 8853, ...
Parents
  • Note: This was originally posted on 25th June 2013 at http://forums.arm.com

    It's an Odroid U2 (Exynos 4412).
    The app I used was es2gears - the only modification I made was to exit after 600 frames instead of running forever...
    I wonder if the errors are related to the UMP module... but I am not sure...

    Thanks.


    Hello memeka,
    [color="#444444"][font="arial"] [/font][/color]Could you give more details on the device you are testing on?
    Do you have a reproducer app that we can begin testing on?
    This will help us identify what the problem is, what the solution may be, and any workarounds that may be of use.

    Thanks in advance,


    McGeagh
Reply
  • Note: This was originally posted on 25th June 2013 at http://forums.arm.com

    It's an Odroid U2 (Exynos 4412).
    The app I used was es2gears - the only modification I made was to exit after 600 frames instead of running forever...
    I wonder if the errors are related to the UMP module... but I am not sure...

    Thanks.


    Hello memeka,
    [color="#444444"][font="arial"] [/font][/color]Could you give more details on the device you are testing on?
    Do you have a reproducer app that we can begin testing on?
    This will help us identify what the problem is, what the solution may be, and any workarounds that may be of use.

    Thanks in advance,


    McGeagh
Children
No data