From owner-freebsd-dtrace@freebsd.org Sun Jul 5 23:32:10 2015 Return-Path: Delivered-To: freebsd-dtrace@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 37F97A14E for ; Sun, 5 Jul 2015 23:32:10 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 05B771FAB; Sun, 5 Jul 2015 23:32:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by pacws9 with SMTP id ws9so86560649pac.0; Sun, 05 Jul 2015 16:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Rt4ikT/eq29V375GofD7UMebLIRq/fl/tLscCtU9NJU=; b=gr4WpzwS0gufVkmF0vayzv1LN/racmCxvW2xc69UB4uaN7J+cF1cE9JDPbpa00t7Yp cdNnw/5gGfHE4OiIeVTExuupHS/Etu4Ld9K4uw2NKYKNg5kGhQUy/wEvgycYFGrSM0BC HfooNrCO04HnaPRaEvl0oOCjhQEkWJrD3HntwwnBOBFOnxlKHxDzKTJai0J8tKgLcikR 1cJ9XxJp5etBs6DKWNO4lnZ5YoodOILAl4vAl0vk0D+8FnNW9JF1A9xexMqF0AaVln6V EFhLOiM8X1VXioaXf+JHE+bR+KE39kzeriHRBwsmOkmsHHB+7YVWR6JrNRAeAaMsm9ea eOlA== X-Received: by 10.70.128.226 with SMTP id nr2mr39197843pdb.139.1436139129045; Sun, 05 Jul 2015 16:32:09 -0700 (PDT) Received: from raichu ([104.232.114.184]) by mx.google.com with ESMTPSA id p1sm15997112pdb.3.2015.07.05.16.32.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2015 16:32:07 -0700 (PDT) Sender: Mark Johnston Date: Sun, 5 Jul 2015 16:32:02 -0700 From: Mark Johnston To: Ryan Stone Cc: abhishek kulkarni , Ryan Stone , "freebsd-dtrace@freebsd.org" Subject: Re: Regarding schedgraph.d Message-ID: <20150705233202.GA70385@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 23:32:10 -0000 On Thu, Jul 02, 2015 at 07:40:21PM -0400, Ryan Stone wrote: > The best that I can offer right now is the Illumos documentation: > > http://dtrace.org/guide/chp-sched.html I wrote and committed some DTrace provider man pages a little while ago. The page for the sched provider is here: https://www.freebsd.org/cgi/man.cgi?query=dtrace-sched&sektion=4&apropos=0&manpath=FreeBSD+11-current > > The caveat is that the types documented there are not implemented in > FreeBSD. Where illumos uses a lwpsinfo_t, FreeBSD uses a struct thread: > > https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l206 > > psinfo_t is replaced by struct proc. > > https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l495 > > cpuinfo_t* arguments are not implemented and passed as NULL. You can > access the current cpu number using the "cpu" variable. > > > Finally, the schedctl-* probes don't apply to the FreeBSD scheduler and > therefore are unimplemented. I removed them in r281702: our sched provider uses FreeBSD types and thus is already incompatible with the Solaris/illumos sched provider, so it didn't make much sense to me to keep them around. > > > On Thu, Jul 2, 2015 at 12:30 PM, abhishek kulkarni > wrote: > > > Thanks Ryan. Those are some very useful tips. Ill get on with trying all > > of those and get back If I have some more concerns. Also, could you be > > having some document which has some logical description about the "sched" > > probes for FreeBSD, which could give details like when is the particular > > probe fired, the probe's arguments etc. Thanks again. > > > > Regards > > Abhishek Kulkarni > > > > On Wed, Jul 1, 2015 at 1:51 PM, Ryan Stone wrote: > > > >> On Tue, Jun 30, 2015 at 7:11 PM, abhishek kulkarni > >> wrote: > >> > >>> Hello Ryan, > >>> > >>> I was looking to schedgraph.d . I need to modify the script for a > >>> single, particular thread. I atleast need to know the thread transitions, > >>> as in the context switches for the particular thread and also the different > >>> states for a single thread. Could you please help with the filters that I > >>> need to add in order to use the script for a single thread or else suggest > >>> me just the nexessary probes that I could use for writing a new script for > >>> a single thread . > >>> > >>> Regards > >>> Abhishek Kulkarni > >>> > >> > >> There are a couple of things that you could filter on, depending on what > >> you know about the thread of interest. The "execname" variable gives the > >> name of the current process. If you're interesting in tracing a > >> single-threaded process, that would be an option. Another variable of > >> interest would be the "curthread" variable. This gives a pointer to the > >> "struct thread" for the current thread. One field that you could trace on > >> would be curthread->td_tid. You can use ps to find your thread id and then > >> run the script as: > >> > >> dtrace -s script.d > >> > >> And in the script, filter with / curthread->td_tid == $1 /. Another > >> field that you could use would be curthread->td_name, which contains the > >> name of the current thread. If your application names threads with > >> "pthreads_set_name_np()", then that name will appear in td_name and you can > >> filter based off of that. > >> > >> An alternative approach would be to use a thread-local variable. If you > >> know that your thread is the only thread that might hit a probe, you can > >> set a thread local variable in that probe and filter on it later on. For > >> example, if your thread is the only thread that will call a function called > >> foobar() in the kernel, you could do this: > >> > >> fbt::foobar:entry > >> { > >> self->interesting = 1; > >> } > >> > >> sched:::off-cpu > >> / self->interesting / > >> { > >> /* trace interesting data here */ > >> } > >> > >> > > > _______________________________________________ > freebsd-dtrace@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" From owner-freebsd-dtrace@freebsd.org Mon Jul 6 00:48:38 2015 Return-Path: Delivered-To: freebsd-dtrace@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 D473DAF6F for ; Mon, 6 Jul 2015 00:48:38 +0000 (UTC) (envelope-from abhya007@gmail.com) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 91E2B1C81; Mon, 6 Jul 2015 00:48:38 +0000 (UTC) (envelope-from abhya007@gmail.com) Received: by ykeo3 with SMTP id o3so14786370yke.0; Sun, 05 Jul 2015 17:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=krpcYjirz8rapEJqlL/FuEyukHiTmT+KiomAWGoancU=; b=rz7OghvD3lSQIUolIaW9bACt5PIBCVFxTGXMrnFGwG/3r/TC5Y458AmhQHtmXsxuoN 2UTBWwKFvStw8fHsmugnydjZjnzePhCl7aDyMU/jZl+OtRRb4FnlkTRMGRzkrw4Q5TOB lwoZI72VaVWi+Y4fenVLPJ1QvzWu3oMMKlPFXudz5OYjmjlKrFUBgnELwfLiqMV1X/I6 IINel5bdsNRT+EgpjKbm0MlpCguSNFBpkBfyLGx9nM5YGW6pgoU/uMLhQzwzZjQDDQVb o998km/LHQBGxslIpsK3baDy/mb86CyYuYTolh/sTFLdE0T9p48oN7yVrHL+GTt0SKzX /QEw== MIME-Version: 1.0 X-Received: by 10.129.137.4 with SMTP id z4mr53054495ywf.145.1436143717590; Sun, 05 Jul 2015 17:48:37 -0700 (PDT) Received: by 10.13.224.6 with HTTP; Sun, 5 Jul 2015 17:48:37 -0700 (PDT) In-Reply-To: <20150705233202.GA70385@raichu> References: <20150705233202.GA70385@raichu> Date: Sun, 5 Jul 2015 17:48:37 -0700 Message-ID: Subject: Re: Regarding schedgraph.d From: abhishek kulkarni To: Mark Johnston Cc: Ryan Stone , Ryan Stone , "freebsd-dtrace@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 00:48:38 -0000 Thanks mark. I will go through all the references mentioned. your answer gives a clear picture of how the sched provider differs for FreeBSD. Thanks and Regards Abhishek Kulkarni On Sun, Jul 5, 2015 at 4:32 PM, Mark Johnston wrote: > On Thu, Jul 02, 2015 at 07:40:21PM -0400, Ryan Stone wrote: > > The best that I can offer right now is the Illumos documentation: > > > > http://dtrace.org/guide/chp-sched.html > > I wrote and committed some DTrace provider man pages a little while ago. > The page for the sched provider is here: > > https://www.freebsd.org/cgi/man.cgi?query=dtrace-sched&sektion=4&apropos=0&manpath=FreeBSD+11-current > > > > > The caveat is that the types documented there are not implemented in > > FreeBSD. Where illumos uses a lwpsinfo_t, FreeBSD uses a struct thread: > > > > > https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l206 > > > > psinfo_t is replaced by struct proc. > > > > > https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l495 > > > > cpuinfo_t* arguments are not implemented and passed as NULL. You can > > access the current cpu number using the "cpu" variable. > > > > > > Finally, the schedctl-* probes don't apply to the FreeBSD scheduler and > > therefore are unimplemented. > > I removed them in r281702: our sched provider uses FreeBSD types and > thus is already incompatible with the Solaris/illumos sched provider, so > it didn't make much sense to me to keep them around. > > > > > > > On Thu, Jul 2, 2015 at 12:30 PM, abhishek kulkarni > > wrote: > > > > > Thanks Ryan. Those are some very useful tips. Ill get on with trying > all > > > of those and get back If I have some more concerns. Also, could you be > > > having some document which has some logical description about the > "sched" > > > probes for FreeBSD, which could give details like when is the > particular > > > probe fired, the probe's arguments etc. Thanks again. > > > > > > Regards > > > Abhishek Kulkarni > > > > > > On Wed, Jul 1, 2015 at 1:51 PM, Ryan Stone wrote: > > > > > >> On Tue, Jun 30, 2015 at 7:11 PM, abhishek kulkarni < > abhya007@gmail.com> > > >> wrote: > > >> > > >>> Hello Ryan, > > >>> > > >>> I was looking to schedgraph.d . I need to modify the script for a > > >>> single, particular thread. I atleast need to know the thread > transitions, > > >>> as in the context switches for the particular thread and also the > different > > >>> states for a single thread. Could you please help with the filters > that I > > >>> need to add in order to use the script for a single thread or else > suggest > > >>> me just the nexessary probes that I could use for writing a new > script for > > >>> a single thread . > > >>> > > >>> Regards > > >>> Abhishek Kulkarni > > >>> > > >> > > >> There are a couple of things that you could filter on, depending on > what > > >> you know about the thread of interest. The "execname" variable gives > the > > >> name of the current process. If you're interesting in tracing a > > >> single-threaded process, that would be an option. Another variable of > > >> interest would be the "curthread" variable. This gives a pointer to > the > > >> "struct thread" for the current thread. One field that you could > trace on > > >> would be curthread->td_tid. You can use ps to find your thread id > and then > > >> run the script as: > > >> > > >> dtrace -s script.d > > >> > > >> And in the script, filter with / curthread->td_tid == $1 /. Another > > >> field that you could use would be curthread->td_name, which contains > the > > >> name of the current thread. If your application names threads with > > >> "pthreads_set_name_np()", then that name will appear in td_name and > you can > > >> filter based off of that. > > >> > > >> An alternative approach would be to use a thread-local variable. If > you > > >> know that your thread is the only thread that might hit a probe, you > can > > >> set a thread local variable in that probe and filter on it later on. > For > > >> example, if your thread is the only thread that will call a function > called > > >> foobar() in the kernel, you could do this: > > >> > > >> fbt::foobar:entry > > >> { > > >> self->interesting = 1; > > >> } > > >> > > >> sched:::off-cpu > > >> / self->interesting / > > >> { > > >> /* trace interesting data here */ > > >> } > > >> > > >> > > > > > _______________________________________________ > > freebsd-dtrace@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org > " > From owner-freebsd-dtrace@freebsd.org Thu Jul 9 19:38:44 2015 Return-Path: Delivered-To: freebsd-dtrace@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 87A5C99708D for ; Thu, 9 Jul 2015 19:38:44 +0000 (UTC) (envelope-from abhya007@gmail.com) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (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 4BDF01513; Thu, 9 Jul 2015 19:38:44 +0000 (UTC) (envelope-from abhya007@gmail.com) Received: by ykeo3 with SMTP id o3so124571036yke.0; Thu, 09 Jul 2015 12:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2TuYd6YBZQuy4gJ3I3UGqnT70frIvnZHtLTISNYIzDI=; b=PDdGJ6X+PURCcUAaWtduLP6K5b2RXpr8QiMpdL4BMsJn1GI0IEcYbHFM7YOVMGDXOd +vPlhNXkmT15PmFGc+aPpw/nMVT/vpsOWQzxJX+RF5PaACOnm8c4QrwkoNRJ7hX7Qaa7 E5qD7mygkMp7WnubjuqmEdpNDNWRriICQ9DX5PBW++HS+3P0iyTVyqQnM3hCOpPB0nTy 0QqYWLkyl/rPlkbVPhr1uzIcbUkKfBJJFxynr2Gmye2xDMKulx5uDCKae+mFiQvxqokA ebaNUx8DvAWBOvb7CcOWKmJXhuBro5QSRHq3YDPHmHYQRUQsa+4MvkHgR+9epltGQQVb EcBQ== MIME-Version: 1.0 X-Received: by 10.170.187.134 with SMTP id d128mr19453637yke.103.1436470723205; Thu, 09 Jul 2015 12:38:43 -0700 (PDT) Received: by 10.13.224.6 with HTTP; Thu, 9 Jul 2015 12:38:43 -0700 (PDT) In-Reply-To: References: <20150705233202.GA70385@raichu> Date: Thu, 9 Jul 2015 12:38:43 -0700 Message-ID: Subject: Re: Regarding schedgraph.d From: abhishek kulkarni To: Mark Johnston Cc: Ryan Stone , Ryan Stone , "freebsd-dtrace@freebsd.org" Content-Type: multipart/mixed; boundary=001a1139cf22300872051a7667a9 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:38:44 -0000 --001a1139cf22300872051a7667a9 Content-Type: text/plain; charset=UTF-8 Hello, I got some very good inputs from you for writing a script that gives the total running time for a particular thread as well as the total time that the particular thread was off cpu. That script is working fine. Now, I want to extend that script for a system wide performance. I need the "running times" and the " off cpu times" for each thread. So, the script should summarize the results at the end of the script for each thread. Is it possible to achieve that using Dtrace and if yes, how. If no, would it need a python like script to summarize the results threadwise. Please find the attached script for a single thread. Regards Abhishek Kulkarni On Sun, Jul 5, 2015 at 5:48 PM, abhishek kulkarni wrote: > Thanks mark. I will go through all the references mentioned. your answer > gives a clear picture of how the sched provider differs for FreeBSD. > > Thanks and Regards > Abhishek Kulkarni > > On Sun, Jul 5, 2015 at 4:32 PM, Mark Johnston wrote: > >> On Thu, Jul 02, 2015 at 07:40:21PM -0400, Ryan Stone wrote: >> > The best that I can offer right now is the Illumos documentation: >> > >> > http://dtrace.org/guide/chp-sched.html >> >> I wrote and committed some DTrace provider man pages a little while ago. >> The page for the sched provider is here: >> >> https://www.freebsd.org/cgi/man.cgi?query=dtrace-sched&sektion=4&apropos=0&manpath=FreeBSD+11-current >> >> > >> > The caveat is that the types documented there are not implemented in >> > FreeBSD. Where illumos uses a lwpsinfo_t, FreeBSD uses a struct thread: >> > >> > >> https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l206 >> > >> > psinfo_t is replaced by struct proc. >> > >> > >> https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l495 >> > >> > cpuinfo_t* arguments are not implemented and passed as NULL. You can >> > access the current cpu number using the "cpu" variable. >> > >> > >> > Finally, the schedctl-* probes don't apply to the FreeBSD scheduler and >> > therefore are unimplemented. >> >> I removed them in r281702: our sched provider uses FreeBSD types and >> thus is already incompatible with the Solaris/illumos sched provider, so >> it didn't make much sense to me to keep them around. >> >> > >> > >> > On Thu, Jul 2, 2015 at 12:30 PM, abhishek kulkarni >> > wrote: >> > >> > > Thanks Ryan. Those are some very useful tips. Ill get on with trying >> all >> > > of those and get back If I have some more concerns. Also, could you be >> > > having some document which has some logical description about the >> "sched" >> > > probes for FreeBSD, which could give details like when is the >> particular >> > > probe fired, the probe's arguments etc. Thanks again. >> > > >> > > Regards >> > > Abhishek Kulkarni >> > > >> > > On Wed, Jul 1, 2015 at 1:51 PM, Ryan Stone wrote: >> > > >> > >> On Tue, Jun 30, 2015 at 7:11 PM, abhishek kulkarni < >> abhya007@gmail.com> >> > >> wrote: >> > >> >> > >>> Hello Ryan, >> > >>> >> > >>> I was looking to schedgraph.d . I need to modify the script for a >> > >>> single, particular thread. I atleast need to know the thread >> transitions, >> > >>> as in the context switches for the particular thread and also the >> different >> > >>> states for a single thread. Could you please help with the filters >> that I >> > >>> need to add in order to use the script for a single thread or else >> suggest >> > >>> me just the nexessary probes that I could use for writing a new >> script for >> > >>> a single thread . >> > >>> >> > >>> Regards >> > >>> Abhishek Kulkarni >> > >>> >> > >> >> > >> There are a couple of things that you could filter on, depending on >> what >> > >> you know about the thread of interest. The "execname" variable >> gives the >> > >> name of the current process. If you're interesting in tracing a >> > >> single-threaded process, that would be an option. Another variable >> of >> > >> interest would be the "curthread" variable. This gives a pointer to >> the >> > >> "struct thread" for the current thread. One field that you could >> trace on >> > >> would be curthread->td_tid. You can use ps to find your thread id >> and then >> > >> run the script as: >> > >> >> > >> dtrace -s script.d >> > >> >> > >> And in the script, filter with / curthread->td_tid == $1 /. Another >> > >> field that you could use would be curthread->td_name, which contains >> the >> > >> name of the current thread. If your application names threads with >> > >> "pthreads_set_name_np()", then that name will appear in td_name and >> you can >> > >> filter based off of that. >> > >> >> > >> An alternative approach would be to use a thread-local variable. If >> you >> > >> know that your thread is the only thread that might hit a probe, you >> can >> > >> set a thread local variable in that probe and filter on it later >> on. For >> > >> example, if your thread is the only thread that will call a function >> called >> > >> foobar() in the kernel, you could do this: >> > >> >> > >> fbt::foobar:entry >> > >> { >> > >> self->interesting = 1; >> > >> } >> > >> >> > >> sched:::off-cpu >> > >> / self->interesting / >> > >> { >> > >> /* trace interesting data here */ >> > >> } >> > >> >> > >> >> > > >> > _______________________________________________ >> > freebsd-dtrace@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace >> > To unsubscribe, send any mail to " >> freebsd-dtrace-unsubscribe@freebsd.org" >> > > --001a1139cf22300872051a7667a9 Content-Type: text/plain; charset=US-ASCII; name="modified_drace.txt" Content-Disposition: attachment; filename="modified_drace.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ibwlkc8z0 I3ByYWdtYSBEIG9wdGlvbiBxdWlldA0KI3ByYWdtYSBEIG9wdGlvbiBidWZwb2xpY3k9cmluZw0K DQpCRUdJTg0Kew0KIGZsYWc9MDsNCiB0aW1lc19vZmZjcHU9MDsNCiBjcHVzdGFydFtjcHVdID0g MDsNCiB0aW1lc19vbmNwdT0wOw0KIGZsYWcxPTA7DQp9DQoNCnNjaGVkOjo6b2ZmLWNwdQ0KL2V4 ZWNuYW1lID09InBpbmciLw0KICAgICAgICB7DQogICAgICAgICAgICAgICBzZWxmLT50cyA9IHRp bWVzdGFtcDsNCiAgICAgICAgICAgICAgIHNlbGYtPm5leHRfdGhyZWFkID0gYXJnc1swXS0+dGRf dGlkOw0KICAgICAgICAgICAgICAgcHJpbnRmKCJ0YWtlbiBvZmYgdGhlIGNwdSxUaGUgbmV4dCB0 aHJlYWQgdG8gcnVuIGlzIDogJWRcbiIsIHNlbGYtPm5leHRfdGhyZWFkKTsNCiAgICAgICAgICAg ICAgIGZsYWc9MjsNCiAgICAgICAgICAgfQ0KDQpzY2hlZDo6Om9uLWNwdQ0KL2V4ZWNuYW1lPT0i cGluZyIgICYmIGZsYWcgPT0yLw0Kew0KICAgICAgICAvKnNlbGYtPmRlbHRhICs9ICh0aW1lc3Rh bXAgLSBzZWxmLT50cykvMTAwMDsqLw0KICAgICAgICAgICAgICB0aW1lc19vbmNwdSs9KHRpbWVz dGFtcC1zZWxmLT50cykvMTAwMDsNCiAgICAgICAgICAgICAvKiBwcmludGYoInRoZSB0aW1lIG9m Zi1jcHUgd2FzIDogJWQgbWljcm8tc2Vjb25kc1xuIixzZWxmLT5kZWx0YSk7ICovDQogICAgICAg ICAgICAgICAgZmxhZz0wOw0KICAgICAgICAgICB9DQoNCnNjaGVkOjo6ZW5xdWV1ZQ0KLyBleGVj bmFtZSA9PSJwaW5nIi8NCnsNCiAgICAgICAgcHJpbnRmKCJhZGRlZCB0byB0aGUgcnVucSBhdCAl WVxuIiwgdGltZXN0YW1wKTsNCn0NCg0Kc2NoZWQ6OjpkZXF1ZXVlDQovYXJnc1swXS0+dGRfbmFt ZSA9PSJwaW5nIi8NCnsNCiAgICAgICAgcHJpbnRmKCJyZW1vdmVkIGZyb20gdGhlIHJ1bnEgYXQg JVlcbiIsdGltZXN0YW1wKTsNCg0KfQ0Kc2NoZWQ6OjpvZmYtY3B1DQogL2NwdXN0YXJ0W2NwdV0g JiYgZXhlY25hbWUgPT0icGluZyIgJiYgZmxhZzE9PTEvDQogew0KDQogICAgICAgIC8qIHNhdmUg ZWxhcHNlZCAqLw0KICAgICAgICB0aW1lc19vbmNwdSArPSAodGltZXN0YW1wIC0gY3B1c3RhcnRb Y3B1XSkvMTAwMDsNCiAgICAgICAgZmxhZzE9MDsNCg0KIH0NCg0KIC8qIFJlY29yZCB0aGUgc3Rh cnQgdGltZSBvZiBhIHRocmVhZCAqLw0KIHNjaGVkOjo6b24tY3B1LA0KIHNjaGVkOjo6cmVtYWlu LWNwdQ0KL2V4ZWNuYW1lID09ICJwaW5nIi8NCiB7DQoNCiAgICAgICBwcmludGYoInRocmVhZCBy dW5uaW5nXG4iKTsNCiAgICAgICBjcHVzdGFydFtjcHVdID0gdGltZXN0YW1wOw0KICAgICAgIGZs YWcxPTE7DQp9DQoNCg0KDQoNCg0KRU5EDQp7DQoNCiAgcHJpbnRmKCItLS0tLS0tWFhYLS0tLS0t LS0tXG50aGUgdG90YWwgdGltZSBvZmYgY3B1IGlzIDogJWRcbiIsdGltZXNfb2ZmY3B1KTsNCiAg cHJpbnRmKCJUaGUgdG90YWwgcnVubmluZyB0aW1lIGZvciB0aGUgdGhyZWFkIGlzIDolZFxuIix0 aW1lc19vbmNwdSk7DQp9DQoNCg== --001a1139cf22300872051a7667a9--