From patchwork Tue Dec 1 15:54:03 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 7738231 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id CA6CD9F1C2 for ; Tue, 1 Dec 2015 15:54:16 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D03AF2068E for ; Tue, 1 Dec 2015 15:54:15 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id D330B20678 for ; Tue, 1 Dec 2015 15:54:14 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2856A6E109; Tue, 1 Dec 2015 07:54:14 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by gabe.freedesktop.org (Postfix) with ESMTPS id B3DC46E109 for ; Tue, 1 Dec 2015 07:54:12 -0800 (PST) Received: by wmww144 with SMTP id w144so178870771wmw.1 for ; Tue, 01 Dec 2015 07:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=BU2pChESPX+5GFd98uA8RqIqeLgkw4vvXCLUz+kiyBw=; b=FhY63doSKAlXhnhYLFwDgDY+u5eQpmoov+9VkYlmA3dAB6OdN4bMirc9HaG6t9vqUh Nff0RFrlIuFzRjEWwY6bGOtk2vgz/pw6wICCPbkTMwm9blP+yQQNRWJSEHaoi+d0PdbJ zUoBnWI9wamXztvMRUmYwaE7ZeHrHdiE4rP/Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=BU2pChESPX+5GFd98uA8RqIqeLgkw4vvXCLUz+kiyBw=; b=M1/8MCTLRPzAUlfkpfrqN+bGf333cNOSr8WQuXQTtNy0KYAJZrGcnasQeM3Twxw6d7 xLfGyJIDqaiOuLIno4v7obldxpIcLeW45Sn+ok0tezKuCtipVVaogIhYPj7AjAb0ZHOH 9Fmq48iBEA+IiUMHjec5h0k2Fo4qapPc/PXbz9FIVmr1CR8Me2XN3z5mMHZv3R+TFwqy VqfqhhX89WyhK4G4nCb+RixHde7kZVvpgLb801lKHyaBNqFQfrySNG546oR6Wua1v4I2 5N9bHyHOdiHXrnS9ABEHeMbq3+brHPUhe8BN4F2R5DvKVc/RFmluIXQoeJdhy+HIm4gY VNqw== X-Gm-Message-State: ALoCoQndQJvWjhcZxDINblqdO2iKr3WHSO0caltusP7jmw7nZEsC2kuxiGjZIxrwAy0A0BEP8fAP X-Received: by 10.28.50.193 with SMTP id y184mr38462201wmy.26.1448985250916; Tue, 01 Dec 2015 07:54:10 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by smtp.gmail.com with ESMTPSA id cw3sm51966264wjb.26.2015.12.01.07.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 07:54:10 -0800 (PST) From: Daniel Vetter To: LKML Date: Tue, 1 Dec 2015 16:54:03 +0100 Message-Id: <1448985243-12829-1-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.5.1 In-Reply-To: <1448983768-22324-1-git-send-email-daniel.vetter@ffwll.ch> References: <1448983768-22324-1-git-send-email-daniel.vetter@ffwll.ch> Cc: Daniel Vetter , Intel Graphics Development , DRI Development , Daniel Vetter , Thomas Gleixner , Arjan van de Ven , Andrew Morton Subject: [Intel-gfx] [PATCH] kernel/latencytop: Add non-scheduler interface for latency reporting X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some sources of significant amounts of latency aren't simple sleeps but instead busy-loops or a series of hundreds of small sleeps simply because the hardware can't do better. Unfortunately latencytop doesn't register these and so they slip under the radar. Hence expose a simplified interface to report additional latencies and export the underlying function so that modules can use this. The example I have in mind are edid reads. The drm subsystem exposes both interfaces to do full probes and to just get at the cached state from the last probe and often userspace developers don't know about the difference and incur unecessary big latencies. And usually the i2c transfer is done with busy-looping or if there is a hw engine it might only be able to transfer a few bytes per sleep/irq cycle. And edid reads take at least 12ms and with crappy hw can easily be a few hundred ms. v2: Simplify #ifdefs a bit (Chris). Cc: Chris Wilson Cc: Thomas Gleixner Cc: Arjan van de Ven Cc: Andrew Morton Signed-off-by: Daniel Vetter --- include/linux/latencytop.h | 9 +++++++++ kernel/latencytop.c | 2 ++ 2 files changed, 11 insertions(+) diff --git a/include/linux/latencytop.h b/include/linux/latencytop.h index e23121f9d82a..6f7c35a0bbfe 100644 --- a/include/linux/latencytop.h +++ b/include/linux/latencytop.h @@ -10,6 +10,9 @@ #define _INCLUDE_GUARD_LATENCYTOP_H_ #include + +#include + struct task_struct; #ifdef CONFIG_LATENCYTOP @@ -50,4 +53,10 @@ static inline void clear_all_latency_tracing(struct task_struct *p) #endif +static inline void +account_latency(int usecs) +{ + account_scheduler_latency(current, usecs, 0); +} + #endif diff --git a/kernel/latencytop.c b/kernel/latencytop.c index a02812743a7e..b066a19fc52a 100644 --- a/kernel/latencytop.c +++ b/kernel/latencytop.c @@ -64,6 +64,7 @@ static DEFINE_RAW_SPINLOCK(latency_lock); static struct latency_record latency_record[MAXLR]; int latencytop_enabled; +EXPORT_SYMBOL_GPL(latencytop_enabled); void clear_all_latency_tracing(struct task_struct *p) { @@ -234,6 +235,7 @@ __account_scheduler_latency(struct task_struct *tsk, int usecs, int inter) out_unlock: raw_spin_unlock_irqrestore(&latency_lock, flags); } +EXPORT_SYMBOL_GPL(__account_scheduler_latency); static int lstats_show(struct seq_file *m, void *v) {