From owner-freebsd-current@FreeBSD.ORG Tue Jan 27 03:01:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54D36E6E; Tue, 27 Jan 2015 03:01:53 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCF64E2F; Tue, 27 Jan 2015 03:01:52 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id 10so10855663lbg.10; Mon, 26 Jan 2015 19:01:50 -0800 (PST) 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=KH+88kTKnBlWwe+9O8xH3mL0EcZ7XJ+nWTzWxkP94A4=; b=o1meekv/yC1us4RrKSPHI/vFGvv46YHr5duuZdBls94BsZwmBbyExxvJev+wJoY7vD jgV2vx3ZEpMTrQwZJ8DrHL/HRfdJ7OaGjim8wmRz9ZUxhAB5MohqTDhUhravW9ubasSz qAShPkN8bBSAoOOkyI+oKN6T9rchb+1H5oYLFjDEUvoVZUOodA+Zn3zzs23Gnk7+Vssg 4eE14aNNr83cjjQPrPxsmWj6XsEh5Xf7yZ25BJbBeT5rWJxmJjaOIxKQ8CPa6fM8hG8s ZWxr18WJ7W7Tj8QEE1XTuw/hZCkWPVUTwY+N8XmlUuy+UYiz9t4Pziut3WQry+cmyjvz Mb3Q== MIME-Version: 1.0 X-Received: by 10.152.191.165 with SMTP id gz5mr1454773lac.37.1422327710765; Mon, 26 Jan 2015 19:01:50 -0800 (PST) Received: by 10.114.78.131 with HTTP; Mon, 26 Jan 2015 19:01:50 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Jan 2015 22:01:50 -0500 Message-ID: Subject: Re: Is anyone using the schedgraph.d script? From: Ryan Stone To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 03:01:53 -0000 Hm, there was one bug in that script. I uploaded a fixed version. The fix was: - printf("%d %d KTRGRAPH group:\"thread\", id:\"%s/%s tid %d\", state:\"runq add\", attributes: prio:%d, linkedto:\"%s/%s tid %d\"\n", cpu, timestamp, args[0]->td_proc->p_comm, args[0]->td_name, args[0]->td_tid, args[0]->td_priority, curthread->td_proc->p_comm, curthread->td_name, args[0]->td_tid); + printf("%d %d KTRGRAPH group:\"thread\", id:\"%s/%s tid %d\", state:\"runq add\", attributes: prio:%d, linkedto:\"%s/%s tid %d\"\n", cpu, timestamp, args[0]->td_proc->p_comm, args[0]->td_name, args[0]->td_tid, args[0]->td_priority, curthread->td_proc->p_comm, curthread->td_name, curthread->td_tid); Note that the last printf argument used args[0] instead of curthread as intended. One other thing that I have noticed with the schedgraph data gathering is that unlike KTR, in dtrace every CPU gathers its data into a CPU-local buffer. This can mean that a CPU that sees a large number of scheduler events will roll over its ring buffer much more quickly than a lightly loaded CPU. This can lead to a confusing or misleading schedgraph output at the beginning of the time period. You can mitigate this problem by allowing dtrace to allocate a larger ring buffer with: #pragma D option bufsize=32m (You can potentially tune it even higher than that, but that's a good place to start) Finally, I've noticed that schedgraph seems to have problems auto-detecting the clock frequency, so I tend to forcifully specify 1GHz (dtrace always outputs time in units of ns, so this is always correct to do with dtrace-gather data)