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/ { _at_[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 >Received on Tue Jan 23 2018 - 10:28:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC