Periodical interrupt storm when playing game with USB keyboard
Johannes Lundberg
johalun0 at gmail.com
Tue Jan 23 11:28:10 UTC 2018
Hi all
Some quick dtracing with play causing lag, vs play not causing lag (that is
not hold down any key on a usb keyboard for too long).
# dtrace -n 'profile-997hz /arg0/ { @[func(arg0)]=count(); }'
Lag version
-- snip --
linuxkpi.ko`idr_find 7
kernel`nanotime 8
kernel`__cap_rights_init 8
kernel`amd64_syscall 8
i915kms.ko`i915_gem_obj_lookup_or_create_vma 8
kernel`selfdfree 9
kernel`feed_matrix_S16LE 11
kernel`callout_lock 11
kernel`uma_zalloc_arg 11
kernel`z_feed_linear_S16LE 12
kernel`0xffffffff80f6877e 12
kernel`copyin 12
kernel`tsc_get_timecount_low_lfence 12
kernel`bzero 13
kernel`fget_unlocked 14
i915kms.ko`gen8_ppgtt_insert_pte_entries 14
kernel`callout_when 16
kernel`0xffffffff80f68fbc 26
kernel`kern_select 32
kernel`lock_mtx 50
kernel`spinlock_enter 53
kernel`bcopy 57
kernel`unlock_mtx 104
i915kms.ko`fw_domains_get 113
* kernel`ukbd_timeout 126
kernel`callout_reset_sbt_on 128
kernel`ukbd_interrupt 136*
* kernel`softclock_call_cc 192*
kernel`memcpy 284
kernel`cpu_idle 4257
* kernel`spinlock_exit 4312
kernel`lock_delay 11921*
kernel`acpi_cpu_idle 15265
No lag version
-- snip --
kernel`free 19
kernel`copyout 20
kernel`copyin 20
linuxkpi.ko`idr_find 21
kernel`selfdfree 24
kernel`tsc_get_timecount_low_lfence 25
kernel`__mtx_lock_flags 28
kernel`uma_zalloc_arg 30
kernel`bzero 31
i915kms.ko`gen8_ppgtt_insert_entries 31
drm.ko`drm_ioctl 32
kernel`fget_unlocked 36
kernel`amd64_syscall 37
kernel`kern_select 49
i915kms.ko`gen8_ppgtt_insert_pte_entries 61
kernel`0xffffffff80f68fbc 78
kernel`bcopy 90
i915kms.ko`fw_domains_get 228
kernel`spinlock_exit 284
kernel`cpu_idle 4698
kernel`acpi_cpu_idle 36288
I also tried rebuilding linux-c6_sdl-1.2 using get time functions in librt
vs libc but no difference.
Will dig deeper next time I have free time to spare.
On Tue, Jan 23, 2018 at 2:33 AM, blubee blubeeme <gurenchan at gmail.com>
wrote:
>
>
> On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
>
>> Hi
>>
>> Yeah the timers eventually get coalesced unless someone's asking for a
>> ridciulously accurate timer value.
>>
>> So is some driver asking for hyper-accurate callout timer that isn't
>> being coalesced? hps, is there any useful debugging to try and find
>> callouts that are requesting stupidly accurate timers? Maybe a dtrace
>> probe on the callout schedule entry point?
>>
>>
>>
>> -adrian
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org
>> "
>>
> I'd say dtrace might be able to get you in the right direction very
> quickly.
>
> I used SDL in the past for android apps and the code is very Linux
> specific. I am sure there's some Linux related timers in there somewhere
> that FreeBSD is returning nothing from and that's what's killing the
> performance.
>
> I can almost guarantee that none of the SDL designers and or programmers
> use any *BSD systems.
>
> The easiest solution would be to go look at the timer code and implement
> something that FreeBSD can work with and try to get that upstream.
>
> These are just a few of the issues that will crop up when devs try to just
> use shims to hook into the Linux kernel. Do the design work up front and
> implement things in a native way or enjoy the jank.
>
> DTrace should be able to point you in the right direction relatively
> quickly.
> The DTraceBook: https://www.amazon.com/DTrace-Dynamic-
> Tracing-Solaris-FreeBSD/dp/0132091518
>
> Best
>
More information about the freebsd-current
mailing list