Date: Tue, 23 Jan 2018 11:27:28 +0000 From: Johannes Lundberg <johalun0@gmail.com> To: blubee blubeeme <gurenchan@gmail.com> Cc: Adrian Chadd <adrian.chadd@gmail.com>, Hans Petter Selasky <hps@selasky.org>, Ian Lepore <ian@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Periodical interrupt storm when playing game with USB keyboard Message-ID: <CAECmPws_NNrrxpaNrqqX6yMN4gcdcUUY_fWD=qMC-GkRuFXrZg@mail.gmail.com> In-Reply-To: <CALM2mEnUm8miuSFpTHbn3q6s9b0bjQ6mM7CWSX_jiTY1dZ3DMQ@mail.gmail.com> References: <CAECmPwvDQBYw=mKJpZfUdKpXSC8GysZKSk0f9qaZEXCvy_QeMA@mail.gmail.com> <e2851846-0678-5cb9-0fce-e9cf49c41a2e@selasky.org> <CAECmPwvgMDBTUjhAERe4bKLgNYCim9bwdHw2JEL0RgTckMjSDw@mail.gmail.com> <CAECmPwtWr0t5_xLgg4NMxnjz317sqnfR9-ttH62szq4fwPdO=Q@mail.gmail.com> <64218617-98d2-0e6e-5872-e44106e61bf7@selasky.org> <1516569725.42536.99.camel@freebsd.org> <CAECmPws07U1=KkqgrjHotjnbPhX53n2L9Jj36guLruTJ-wc%2BCw@mail.gmail.com> <0aceb3ff-4938-1b29-d493-d83ce82cc853@selasky.org> <CAECmPwvr2on6_DDehnHd%2BRq1a1r2s-ib99MsabDSbxGo7Ykuhw@mail.gmail.com> <CAJ-VmoktYt4q4LsQ8x-n4xkmH=x6O=vWXUO-Zk4Gj74x8EGAFA@mail.gmail.com> <CALM2mEnUm8miuSFpTHbn3q6s9b0bjQ6mM7CWSX_jiTY1dZ3DMQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com>
wrote:
>
>
> On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd <adrian.chadd@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@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAECmPws_NNrrxpaNrqqX6yMN4gcdcUUY_fWD=qMC-GkRuFXrZg>