Re: [diamon-discuss] Diamon Meeting on Tuesday February 9th, 2016, at 11h EDT (15h UTC)

Hi Mathieu,

This looks like a very interesting approach and I've read the Blog,
but unfortunately I can't make the 9th.

I don't think I would have much to contribute, but I am certainly
interested in what others say. Could the session be recorded, or
meeting notes posted? - Otherwise I'd be available from the 15th on,
in case you'd consider moving the session.

Two questions came up for me when reading the blog,

1. Julien writes  "We are not trying to solve a problem related to the interrupts
   being masked for too long (ftrace already has some tools to help with that)."
   Which are those tools? Any pointer would be appreciated.

2. I really like the general usefulness of the latency_tracker and the many clever
    ways it can be configured / leveraged - but it feels like an expert tool to me,
    where you'd very clearly have to know what you're doing. Are there any ideas
    making such expert tools more usable and discoverable by general users ?

Many thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mathieu Desnoyers
Sent: Thursday, January 28, 2016 9:09 PM
To: [email protected]
Subject: [diamon-discuss] Diamon Meeting on Tuesday February 9th, 2016, at 11h EDT (15h UTC)

Hi,

Following the blog post published two weeks ago [1], we would like to propose organizing a phone meeting with all interested members of this workgroup on February 9th to gather feedback and ideas for improvement on the subject of measuring and detecting high response time.

At EfficiOS, we have developed a kernel module for monitoring at run-time the delay between the moment the kernel starts processing an interrupt
(do_IRQ) and the moment the target task gets scheduled in or has finished processing the data.

When a high latency is detected, it emits a tracepoint event and can wakeup a user-space script to take arbitrary actions as soon as possible.

The main intent is to provide an entry point in a kernel trace. After that, everyone has their own methodology to process the trace. The blog post illustrates what we can do with LTTng as an example but the detection and triggers are not coupled with any tracer.

The proposed agenda is a discussion around these points:
- presentation of the scope of the problem
- limitation of the current tools
- overview of the latency_tracker module applied for this use-case
-- current state
-- use-cases
-- future plans
- from the audience: comments, ideas, other approaches, etc.

If you have other points you would like to discuss around this subject, please let me know and I will add them.

Also, if you wish to attend but can't make it at the proposed date and time, let us know.

The details for the conference call will be sent soon.

Thanks,

Julien & Mathieu

[1] https://lttng.org/blog/2016/01/06/monitoring-realtime-latencies/

--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
diamon-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/diamon-discuss