From owner-freebsd-current@freebsd.org Tue Jan 23 12:06:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4A33ECF552 for ; Tue, 23 Jan 2018 12:06:25 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7706B77E4A; Tue, 23 Jan 2018 12:06:25 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x236.google.com with SMTP id t22so675232ioa.7; Tue, 23 Jan 2018 04:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HGM88yBs0KT2Ym+tj/xVpuZic82Yw4X+FSvcbTCyTWY=; b=sn5bimvu1o5N+wUEeNsnd9Xh+gluHCKdlc7vgKwgNx8roDorAMsGzQ5FQLZasd5N9l fchy5cAgGzD9LsuWOL3IrHfkJ+jTtQnHrQq6hAJ8OhOanEc4RpUcbvz72fO6TLg7pek+ cATMcb2cM6EVa7KEZ086stKIGW7RsPLFCS44/ieFBtG1eKVb5/a4FhGJ8Hw5/AOhf6Mi uTeZo308v4/qRFvxpnrQ8lvdRXLJsp0BQU3DBJGOv2hYHhmcjace1unEZY7mSu4JJPt4 Uh5/XAmIXbmt4ZFm9RCHDQYLE7696vtmHDmdonCIjVBNlC+INIxuwrQC8jrxAO5uJVm4 6Kqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HGM88yBs0KT2Ym+tj/xVpuZic82Yw4X+FSvcbTCyTWY=; b=H1CLqQsiQ4DcUOtS8//s+7QICAFEVSrwxKpXKmhxh0X9YAJzBmdQsasklBZV2uv0P8 oqGtSd1V74oeKaNu8ZXv5O4vm3yPzJcVHfVq5z7stb2ZjHitOYAbj7uOk8Z/t6d1uTtS DQ+IIMv7iro7V4fhwItAYcGtfobyjbtTAqgABlflJ+9GO3qxxiCporaYMLuzF6r0/NO1 5MkVeOOrnAgPrzbvNXWsfdUScPxgL9I4hmYcmekKg9f+sNzOrAeOzgg839SwwLhlrq5f r/lw5ooAaTXDhj980SqrlUXrjYSwNNgQ0Wb8Hkm07tZPIKBLl6snmfpt+ji4tGeW86ZR Zdgw== X-Gm-Message-State: AKwxyteOGbjx23OGiYYmAm8PAvdWhoqi3L44N/mDOP8ct6Uky/T13usG qOmLsb6R7d1feLeh01Xo2LMKUmoUJj9Rx/UqKY7mYA== X-Google-Smtp-Source: AH8x227MBAtjhkbUmyH71qxowxyG5kZeyVwEjfHd6dN0mBJhDSNd4waH59SCg5YUhIxxXzHx/MEDHyZ8Ja7koQ07MvE= X-Received: by 10.107.97.24 with SMTP id v24mr3289532iob.296.1516709184633; Tue, 23 Jan 2018 04:06:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.10.97 with HTTP; Tue, 23 Jan 2018 04:06:24 -0800 (PST) In-Reply-To: References: <64218617-98d2-0e6e-5872-e44106e61bf7@selasky.org> <1516569725.42536.99.camel@freebsd.org> <0aceb3ff-4938-1b29-d493-d83ce82cc853@selasky.org> From: blubee blubeeme Date: Tue, 23 Jan 2018 20:06:24 +0800 Message-ID: Subject: Re: Periodical interrupt storm when playing game with USB keyboard To: Johannes Lundberg Cc: Adrian Chadd , Hans Petter Selasky , Ian Lepore , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 12:06:25 -0000 On Tue, Jan 23, 2018 at 7:27 PM, Johannes Lundberg wrote: > 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 > A question on the mailing list about spinlocks and high cpu time: https://lists.freebsd.org/pipermail/freebsd-questions/2008-October/183943.html Although I think that for USB you can most likely fully replace the spinlock with a lock free queue, stack allocator and a ring buffer. Tony Van Eerd has been doing some very interesting work on lock free queue and refined his implementation, his talk from this year's cpp con looks very promising. You can check it out here: https://www.youtube.com/watch?v=HP2InVqgBFM Locks just have overhead that can't be avoided, with something like USB you can use a heap allocator, a ring buffer and a lock free queue and that should be able to get rid of the lock. I remember looking at the USB stack a while ago, there's one global lock or something like that and looking at the DTrace logs it's definitely that causing issues somehwere. It'll need testing though. > > > 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 > wrote: > >> >> >> On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd >> 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@f >>> reebsd.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 >> > >