Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754904AbbLAPyN (ORCPT ); Tue, 1 Dec 2015 10:54:13 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:36577 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752959AbbLAPyM (ORCPT ); Tue, 1 Dec 2015 10:54:12 -0500 From: Daniel Vetter To: LKML Cc: Intel Graphics Development , DRI Development , Daniel Vetter , Chris Wilson , Thomas Gleixner , Arjan van de Ven , Andrew Morton , Daniel Vetter Subject: [PATCH] kernel/latencytop: Add non-scheduler interface for latency reporting 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> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2734 Lines: 81 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) { -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/