From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 20 21:23:13 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A416D106567E; Thu, 20 Mar 2008 21:23:13 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.freebsd.org (Postfix) with ESMTP id 818E18FC14; Thu, 20 Mar 2008 21:23:13 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms071.mailsrvcs.net ([172.18.12.131]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JY100DKKSQOGIH1@vms042.mailsrvcs.net>; Thu, 20 Mar 2008 16:23:13 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms071.mailsrvcs.net (Verizon Webmail) with HTTP; Thu, 20 Mar 2008 16:23:12 -0500 (CDT) Date: Thu, 20 Mar 2008 16:23:12 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [65.242.108.162] To: John Baldwin , Matthew Dillon Message-id: <12362883.2752181206048192946.JavaMail.root@vms071.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 20 Mar 2008 21:43:32 +0000 Cc: freebsd-hackers@freebsd.org, walt Subject: Re: Re: vkernel & GSoC, some questions 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: Thu, 20 Mar 2008 21:23:13 -0000 >From: Matthew Dillon >To: John Baldwin >:Except that you still need "real" hardware concurrency to see some races and >:that is important for testing. I'd worry about the overhead of any > > Hardware and vkernel/qemu environments exercise different code paths > and different timing mechanics. Certain bugs show up on vkernel's > more readily then on real hardware, while other bugs show up more > readily on real hardware then on vkernel's. I don't think one is When testing multi-threaded code I sometimes insert artificial delays at different strategic locations. This widens any present race windows and makes the related bugs show up every time instead of once in a while. Of course, the resulting code works slower during the tests too :-) -SB