From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 2 09:37:12 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5030016A41F for ; Wed, 2 Nov 2005 09:37:12 +0000 (GMT) (envelope-from viktor.vasilev@stud.tu-darmstadt.de) Received: from lnx117.hrz.tu-darmstadt.de (lnx117.hrz.tu-darmstadt.de [130.83.174.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A98D43D4C for ; Wed, 2 Nov 2005 09:37:11 +0000 (GMT) (envelope-from viktor.vasilev@stud.tu-darmstadt.de) Received: from ilium.0xdeadc0de.net (ABC216.ram1st.wh.tu-darmstadt.de [130.83.20.203]) (authenticated bits=0) by lnx117.hrz.tu-darmstadt.de (8.12.10/8.12.10) with ESMTP id jA29au3i014039 for ; Wed, 2 Nov 2005 10:36:56 +0100 Received: by ilium.0xdeadc0de.net (nbSMTP-1.00) for uid 1001 viktor.vasilev@stud.tu-darmstadt.de; Wed, 2 Nov 2005 10:37:02 +0100 (CET) Date: Wed, 2 Nov 2005 10:37:02 +0100 From: Viktor Vasilev To: freebsd-hackers@freebsd.org Message-ID: <20051102093702.GB624@ilium.0xdeadc0de.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 5.4-RELEASE i386 User-Agent: mutt-ng devel (FreeBSD) X-TUD-HRZ-MailScanner: Found to be clean X-TUD-HRZ-MailScanner-SpamCheck: X-MailScanner-From: viktor.vasilev@stud.tu-darmstadt.de Subject: sysprof, interrupting threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 09:37:12 -0000 Hello fellow hackers, I was thinking of porting the linux sysprof kernel and userland tools to FreeBSD. I spent some time studying the code and wrote a skeleton driver that uses the callout mechanism to wake up periodically. That was only to discover, that the context in which the driver awakes is that of the software clock interrupt. The linux sysprof driver uses a timer hook API that was introduced in the 2.6 kernel series. I don't have a profound understanding of the linux kernel but it seems that the hook gets executed in the process context that was currently executing as the tick happened. My question is, is there a better place to plant the code, so that it executes periodically in the context of the current runnging thread? I was also thinking of traversing the list of processes but I'm not sure if I can tell which one was interrupted by the swi. Any suggestions are wellcome. Best regards, Viktor -- I think and think for months and years. Ninety nine times, the conclusion is false. The hundredth time I am right. -- Albert Einstein