From owner-freebsd-current@freebsd.org Tue Jan 23 11:28:10 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 88F11ECC8AB for ; Tue, 23 Jan 2018 11:28:10 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 0BBC47609A; Tue, 23 Jan 2018 11:28:10 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id i186so1122674wmi.4; Tue, 23 Jan 2018 03:28:09 -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=OoMpC7FYu9gf8eYInDUSRwJOydnf1kvBJz/+ZGPx3M0=; b=r639+ksMUUg6HlqgJCo/Uy65ZBq0m/MUHzazisVTyyTHyotF9FNi88GbnPhvigCq6L I1XpGu+ez76RhyeWPU7k1xd0EubMdT7Teq5VcPGe9whOyX6RpwABSPWaRYtqlcaahZNF GU3rpCa28AULzCELlBmWPPj+sYFJXTT1+5MmjXVYYf4tcvbKE90ZAlU/sOhJJ6q5O4xa hhFuBsvpXFoV3yEABza5T8cKNIDtxd/KgdXBrTbUTJrSqW45s+1h2WrARRAlgQfYZ77v ainOI/c1KfHULjmwKG0I/bhObD3sN9mdyEiRRx4GyYTuus/LyoV5BUqXDgepsujIg5Ep MTNg== 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=OoMpC7FYu9gf8eYInDUSRwJOydnf1kvBJz/+ZGPx3M0=; b=elJ03sbI0EnZyVs1YiSTIY0FHJzYPdo5NOez9Ije8Hh/J/51lKtgk7/rHRAE4P8Qx+ aFI9I3/EmVgOeER5Ph8E4RVUgvaMbjtBIHMEEuFwmUXHxNnFzfcMHTqr7J+9QORsJ1lo IqOWhEkfYs5PTxG6159vAq/2cdZ6ulrzjeRfmRsZ5j8Gkil2USNCrL+kGIpysViu1ZBo sq0INOzoQ75KYvromjqRBc4zyjpJg2M1bzKYPJBS3LM7N2eqzCR7c/GYUJr0vZI/vOM1 r2XmTK1lgJwIjX+BVXiTTYKaouthAinDaBl5NXWw8GF89o5Jfzhqui9wvadNM+evDyxw zAuw== X-Gm-Message-State: AKwxytd+jHzq6vArF8X8F3QxnkWUtFWZ4bdDVN8/WIW18wl0HGAh5FBG jOs8z38Mti60tFpTWFpQEpzDL7QsFg6yfLgybdI= X-Google-Smtp-Source: AH8x2277T433k/0WKV7E6x8m8dU/5UNuDtfYRhHrE6Lj0xTCEVxBGw5NG2gcBaLhhehgP57e8QSHr4pB/knaGhC1BBI= X-Received: by 10.28.111.219 with SMTP id c88mr1760233wmi.41.1516706888408; Tue, 23 Jan 2018 03:28:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.136.187 with HTTP; Tue, 23 Jan 2018 03:27:28 -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: Johannes Lundberg Date: Tue, 23 Jan 2018 11:27:28 +0000 Message-ID: Subject: Re: Periodical interrupt storm when playing game with USB keyboard To: blubee blubeeme 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 11:28:10 -0000 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 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@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 >