From owner-freebsd-dtrace@freebsd.org Thu Jul 2 16:30:39 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 507179937FA for ; Thu, 2 Jul 2015 16:30:39 +0000 (UTC) (envelope-from abhya007@gmail.com) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 10AA81E82; Thu, 2 Jul 2015 16:30:39 +0000 (UTC) (envelope-from abhya007@gmail.com) Received: by ykdv136 with SMTP id v136so73212594ykd.0; Thu, 02 Jul 2015 09:30:38 -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=hh5d9eN9OEH2C9QvLR+hQXvYW7TgFg24mY9JuQFLPNs=; b=J85HprQAGlQ8Tc8rWfjVxpER4M/dz65kCodG1YTyrPZg3uNd5nsU3Q5duVfhOtSO0J ZCeTGQyra0VKP2c4ILTacuhYJCrqKnfLicBiPqcgUqhWD/9UV01pJUxbNbO3xydJZIaN Y483uT4b/FsHjGQXN+CBj2EBg3550V8rFR7zNebuwC+a6pI+oNYlZxVUI8VrLa0w7J2t fMpW+Q+k24cfURe4n4G1L3uS9TMMBIj3xifxFOX1TCFuI8JRnOe/n4SNHKKILJb1EQ15 zdykmsJH80LS54RsspI8yEQltxkzDfhkPfRv1BTChMkx8dskvnUoT3+O/vXaMMrUI9zx G+ew== MIME-Version: 1.0 X-Received: by 10.129.102.213 with SMTP id a204mr4003408ywc.19.1435854638204; Thu, 02 Jul 2015 09:30:38 -0700 (PDT) Received: by 10.13.224.6 with HTTP; Thu, 2 Jul 2015 09:30:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jul 2015 09:30:38 -0700 Message-ID: Subject: Re: Regarding schedgraph.d From: abhishek kulkarni To: Ryan Stone 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 16:30:39 -0000 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 */ > } > >