From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 16 Feb 2016 16:22:00 -0500 From: Julien Desfossez Message-ID: <20160216212200.GG6594@sinkpad> References: <1478740846.7068.1454011725322.JavaMail.zimbra@efficios.com> <146B1557584B0B4DBD25ABAD45EF70F0F6E5164C@ALA-MBB.corp.ad.wrs.com> <1718754721.21848.1455657328492.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1718754721.21848.1455657328492.JavaMail.zimbra@efficios.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [diamon-discuss] Diamon Meeting on Tuesday February 9th, 2016, at 11h EDT (15h UTC) List-Id: DiaMon diagnostic and monitoring workgroup general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mathieu Desnoyers Cc: diamon-discuss@lists.linuxfoundation.org, Mike Dolan Mike confirmed to me that the recording did not work, so I am annotating the slides to add a little bit more context and I will send them very soon. Julien On 16-Feb-2016 09:15:28 PM, Mathieu Desnoyers wrote: > Hi Martin, >=20 > We are trying to clarify with Mike Dolan whether the recording > feature of the conference system was working or not during the > call. As far as I can see, it did not appear to have worked, > even though the option was enabled in the conference system. :-( >=20 > Thanks, >=20 > Mathieu >=20 > ----- On Feb 4, 2016, at 4:31 AM, Oberhuber, Martin Martin.Oberhuber@wi= ndriver.com wrote: >=20 > > Hi Mathieu, > >=20 > > This looks like a very interesting approach and I've read the Blog, > > but unfortunately I can't make the 9th. > >=20 > > 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. > >=20 > > Two questions came up for me when reading the blog, > >=20 > > 1. Julien writes "We are not trying to solve a problem related to th= e > > interrupts > > being masked for too long (ftrace already has some tools to help wi= th that)." > > Which are those tools? Any pointer would be appreciated. > >=20 > > 2. I really like the general usefulness of the latency_tracker and th= e many > > clever > > ways it can be configured / leveraged - but it feels like an exper= t 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 u= sers ? > >=20 > > Many thanks, > > Martin > > -- > > Martin=A0Oberhuber, SMTS / Product Owner - Development Tools, Wind Ri= ver > > direct +43.662.457915.85=A0=A0fax +43.662.457915.6 > >=20 > >=20 > > -----Original Message----- > > From: diamon-discuss-bounces@lists.linuxfoundation.org > > [mailto:diamon-discuss-bounces@lists.linuxfoundation.org] On Behalf O= f Mathieu > > Desnoyers > > Sent: Thursday, January 28, 2016 9:09 PM > > To: diamon-discuss@lists.linuxfoundation.org > > Subject: [diamon-discuss] Diamon Meeting on Tuesday February 9th, 201= 6, at 11h > > EDT (15h UTC) > >=20 > > Hi, > >=20 > > Following the blog post published two weeks ago [1], we would like to= propose > > organizing a phone meeting with all interested members of this workgr= oup on > > February 9th to gather feedback and ideas for improvement on the subj= ect of > > measuring and detecting high response time. > >=20 > > 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 fini= shed > > processing the data. > >=20 > > 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. > >=20 > > 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 pos= t > > illustrates what we can do with LTTng as an example but the detection= and > > triggers are not coupled with any tracer. > >=20 > > 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. > >=20 > > If you have other points you would like to discuss around this subjec= t, please > > let me know and I will add them. > >=20 > > Also, if you wish to attend but can't make it at the proposed date an= d time, let > > us know. > >=20 > > The details for the conference call will be sent soon. > >=20 > > Thanks, > >=20 > > Julien & Mathieu > >=20 > > [1] https://lttng.org/blog/2016/01/06/monitoring-realtime-latencies/ > >=20 > > -- > > Mathieu Desnoyers > > EfficiOS Inc. > > http://www.efficios.com > > _______________________________________________ > > diamon-discuss mailing list > > diamon-discuss@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/diamon-discuss >=20 > --=20 > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com > _______________________________________________ > diamon-discuss mailing list > diamon-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/diamon-discuss