From owner-freebsd-dtrace@freebsd.org Thu Jul 2 23:40:22 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 5C51E993D64 for ; Thu, 2 Jul 2015 23:40:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 1DFE81193; Thu, 2 Jul 2015 23:40:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by iebmu5 with SMTP id mu5so66883190ieb.1; Thu, 02 Jul 2015 16:40:21 -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=WtBxDvgEKKhH+twXP0JzysIk48JwZ87Kup79u8qFJIo=; b=fygVnGiOsD6usWDLhbsRUt2eXVDWNBYvp5OqYRvdcgXXO5tTIiwMd8mOPWZCNL5rAJ kVIRHueacXGqWHo3Q95Ye6V/AooZUQA0TKksKFY9XckNtQ27uSZ/nXvcq0UIXSK8s4sn vxrDyw+/+tFktaYieVikS4jLuzcYzqlb8BtGTZaaeThgo8Qd8Z8vShShdAAFDt+FFglb 7eQNH2A0XCXryhJ5LlOM42s2Sq+44IUFd0/6VrqNV/kYFH/jTbuUrgj5djQIXEolcFm0 +3mKdsNk/GScsdFR9QsjlGCA0h9wyfezn3VRE2XPvp3ub0tAnIA6AvC1cm7bRfoJ5oIN mwoA== MIME-Version: 1.0 X-Received: by 10.107.10.212 with SMTP id 81mr41993180iok.89.1435880421594; Thu, 02 Jul 2015 16:40:21 -0700 (PDT) Received: by 10.107.145.68 with HTTP; Thu, 2 Jul 2015 16:40:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jul 2015 19:40:21 -0400 Message-ID: Subject: Re: Regarding schedgraph.d From: Ryan Stone To: abhishek kulkarni Cc: 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: Thu, 02 Jul 2015 23:40:22 -0000 The best that I can offer right now is the Illumos documentation: http://dtrace.org/guide/chp-sched.html 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. 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 */ >> } >> >> >