From owner-freebsd-emulation@FreeBSD.ORG Sun May 1 02:41:14 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 380B8106566B for ; Sun, 1 May 2011 02:41:14 +0000 (UTC) (envelope-from aqqa11@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id E739A8FC0C for ; Sun, 1 May 2011 02:41:13 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CGnG3j7zhJfKgdbE3AfcxSduKyL3t4iQ+lF5Kj3AoYLaKN/gcS1DPstHUii/rufU; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.28] (helo=mswamui-blood.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QGMOZ-0007lK-3X for freebsd-emulation@freebsd.org; Sat, 30 Apr 2011 22:28:27 -0400 Received: from 96.242.250.147 by webmail.earthlink.net with HTTP; Sat, 30 Apr 2011 22:28:26 -0400 Message-ID: <6157936.1304216907022.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Sat, 30 Apr 2011 22:28:26 -0400 (GMT-04:00) From: typo W To: freebsd-emulation@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 2552ff5019365d7e94f5150ab1c16ac02930b881f11d255e96d5891b9c8072795c1255edc620fbf2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.28 Subject: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: typo W List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 02:41:14 -0000 Hi, I'm brand new to virtualbox, so pardon me in case I made stupid mistakes. I created a FreeBSD guest out of the regular virtualbox port (3.2.12) on FreeBSD 8.2, then timed the copying of a 320MB binary file to another file, which took 4 seconds, ie, 80MB/s. On an identical hardware I created a CentOS guest out of KVM running on CentOS, and the same operation only takes 1 second. On both hosts, the copy takes 1 second. That is, virtualbox slowed the copying to 1/4 speed on my guest FreeBSD. Both hosts are Dell R710, with 6 x 600GB 15K SAS drives forming a RAID6 with R700 controller with 512MB cache. I'm testing in preparation of production servers, so would prefer regular ports, ie, 4.0.6 tar ball is out of question for now. From owner-freebsd-emulation@FreeBSD.ORG Sun May 1 05:39:52 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9561106566C for ; Sun, 1 May 2011 05:39:52 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 560AE8FC0C for ; Sun, 1 May 2011 05:39:52 +0000 (UTC) Received: from [90.152.173.99] (90.152.173.99) by groupware.itac.at (Axigen) with (CAMELLIA256-SHA encrypted) ESMTPSA id 1677BC; Sun, 1 May 2011 07:39:54 +0200 From: Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= To: typo W , freebsd-emulation@freebsd.org X-Mailer: Modest 3.90.7 References: <6157936.1304216907022.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> In-Reply-To: <6157936.1304216907022.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Content-Type: text/plain; charset=utf-8 Content-ID: <1304228386.8814.4.camel@Nokia-N900-42-11> Date: Sun, 01 May 2011 07:39:47 +0200 Message-Id: <1304228387.8814.5.camel@Nokia-N900-42-11> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0201.4DBCF227.007D,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard =?ISO-8859-1?Q?Fr=F6hlich?= List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 05:39:52 -0000 On So.,  1. Mai. 2011 04:28:26 CEST, typo W wrote: > Hi, I'm brand new to virtualbox, so pardon me in case I made stupid > mistakes.  I created a FreeBSD guest out of the regular virtualbox port > (3.2.12) on FreeBSD 8.2, then timed the copying of a 320MB binary file > to another file, which took 4 seconds, ie, 80MB/s.  On an identical > hardware I created a CentOS guest out of KVM running on CentOS, and the > same operation only takes 1 second.  On both hosts, the copy takes 1 > second.  That is, virtualbox slowed the copying to 1/4 speed on my guest > FreeBSD. > > Both hosts are Dell R710, with 6 x 600GB 15K SAS drives forming a RAID6 > with R700 controller with 512MB cache. > > I'm testing in preparation of production servers, so would prefer > regular ports, ie, 4.0.6 tar ball is out of question for now. Virtualbox 4.0 uses async i/o so that will probably improve performance. Please also use the new ahci kernel module in the guest because that also significantly improves i/o performance. Virtualbox 4.0.6 will be committed to the tree next week. From owner-freebsd-emulation@FreeBSD.ORG Sun May 1 09:01:05 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2021F106566B for ; Sun, 1 May 2011 09:01:05 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id D9B718FC0C for ; Sun, 1 May 2011 09:01:04 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p41913tF003448 for ; Sun, 1 May 2011 02:01:04 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DBD2153.2030902@mittelstaedt.us> Date: Sun, 01 May 2011 02:01:07 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <6157936.1304216907022.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> In-Reply-To: <6157936.1304216907022.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 09:01:05 -0000 On 4/30/2011 7:28 PM, typo W wrote: > Hi, I'm brand new to virtualbox, so pardon me in case I made stupid > mistakes. I created a FreeBSD guest out of the regular virtualbox > port (3.2.12) on FreeBSD 8.2, then timed the copying of a 320MB > binary file to another file, which took 4 seconds, ie, 80MB/s. On an > identical hardware I created a CentOS guest out of KVM running on > CentOS, and the same operation only takes 1 second. On both hosts, > the copy takes 1 second. That is, virtualbox slowed the copying to > 1/4 speed on my guest FreeBSD. > > Both hosts are Dell R710, with 6 x 600GB 15K SAS drives forming a > RAID6 with R700 controller with 512MB cache. > Try some file copies at the base OS and let us know the results. I would guess that the FreeBSD hardware RAID device driver for the R700 controller isn't using the hardware write caching of the controller. When the FreeBSD host OS got the file write call from the virtual box it should have issued the write to the disk controller and then returned immediately since the write should have gone into the hardware cache of the controller. you can also try playing with the sync/async options in the host OS. See the mount command for details. it is kind of pointless to do sync writes on a caching hardware controller because the entire point of sync writes is to keep the data from being scrambled in a crash or if there is sudden power loss - but the cache in the hardware array card is more than capable of screwing the filesystem if that happens. Ted > I'm testing in preparation of production servers, so would prefer > regular ports, ie, 4.0.6 tar ball is out of question for now. > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To > unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Sun May 1 20:40:10 2011 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C2010656D9 for ; Sun, 1 May 2011 20:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3FF8FC08 for ; Sun, 1 May 2011 20:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p41Ke9Ar041885 for ; Sun, 1 May 2011 20:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p41Ke97L041884; Sun, 1 May 2011 20:40:09 GMT (envelope-from gnats) Date: Sun, 1 May 2011 20:40:09 GMT Message-Id: <201105012040.p41Ke97L041884@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Marcin Cieslak Cc: Subject: Re: kern/153887: [linux] Linux emulator not understand STB_GNU_UNIQUE binding X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcin Cieslak List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 20:40:10 -0000 The following reply was made to PR kern/153887; it has been noted by GNATS. From: Marcin Cieslak To: bug-followup@FreeBSD.org, yuri@tsoft.com Cc: Subject: Re: kern/153887: [linux] Linux emulator not understand STB_GNU_UNIQUE binding Date: Sun, 1 May 2011 20:36:14 +0000 Hello, I don't think that this area belongs to the linux emulator, as this problem probably is related to the runtime linker and not the kernel. Two questions, though: (1) did you run "brandelf -t Linux" on your program binary? (2) can you provide us with a small testcase (like a one-line program trying to use libstdc++ in a smiliar way)? Thanks in advance, //Marcin From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 05:54:24 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EDAA106566B for ; Mon, 2 May 2011 05:54:24 +0000 (UTC) (envelope-from aqqa11@earthlink.net) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by mx1.freebsd.org (Postfix) with ESMTP id DB05A8FC12 for ; Mon, 2 May 2011 05:54:23 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qwgvaBpnWbxTZ0LGTXDeFZPnZa7tOq9j2T9YRaV7riPcztgiQas9FKjHM5wBpajM; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.28] (helo=mswamui-blood.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QGm5P-0003g4-9w for freebsd-emulation@freebsd.org; Mon, 02 May 2011 01:54:23 -0400 Received: from 96.242.250.147 by webmail.earthlink.net with HTTP; Mon, 2 May 2011 01:54:22 -0400 Message-ID: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Mon, 2 May 2011 01:54:22 -0400 (EDT) From: John To: freebsd-emulation@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 2552ff5019365d7e94f5150ab1c16ac02930b881f11d255efb643ccd5417debb5b975860f99a21d0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.28 Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 05:54:24 -0000 -----Original Message----- >From: Ted Mittelstaedt > >On 4/30/2011 7:28 PM, typo W wrote: >> Hi, I'm brand new to virtualbox, so pardon me in case I made stupid >> mistakes. I created a FreeBSD guest out of the regular virtualbox >> port (3.2.12) on FreeBSD 8.2, then timed the copying of a 320MB >> binary file to another file, which took 4 seconds, ie, 80MB/s. On an >> identical hardware I created a CentOS guest out of KVM running on >> CentOS, and the same operation only takes 1 second. On both hosts, >> the copy takes 1 second. That is, virtualbox slowed the copying to >> 1/4 speed on my guest FreeBSD. >> >> Both hosts are Dell R710, with 6 x 600GB 15K SAS drives forming a >> RAID6 with R700 controller with 512MB cache. >> > >Try some file copies at the base OS and let us know the results. > >I would guess that the FreeBSD hardware RAID device driver for >the R700 controller isn't using the hardware write caching of >the controller. When the FreeBSD host OS got the file write >call from the virtual box it should have issued the write to the >disk controller and then returned immediately since the write should >have gone into the hardware cache of the controller. > >you can also try playing with the sync/async options in the host OS. >See the mount command for details. it is kind of pointless to do >sync writes on a caching hardware controller because the entire >point of sync writes is to keep the data from being scrambled >in a crash or if there is sudden power loss - but the cache in the >hardware array card is more than capable of screwing the filesystem >if that happens. > >Ted > > On both the FreeBSD host and the CentOS host, the copying only takes 1 second, as tested before. Actually, the classic "dd" test is slightly faster on the FreeBSD host than on the CentOS host. The storage I chose for the virtualbox guest is a SAS controller. I found by default it did not enable "Use Host I/O Cache". I just enabled that and rebooted the guest. Now the copying on the guest takes 3 seconds. Still, that's clearly slower than 1 second. Any other things I can try? I love FreeBSD and hope we can sort this out. Thanks, John From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 11:06:57 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 099341065678 for ; Mon, 2 May 2011 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D18648FC19 for ; Mon, 2 May 2011 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p42B6uVu064057 for ; Mon, 2 May 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p42B6uDB064055 for freebsd-emulation@FreeBSD.org; Mon, 2 May 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 May 2011 11:06:56 GMT Message-Id: <201105021106.p42B6uDB064055@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/156353 emulation [ibcs2] ibcs2 binaries that execute on 4.x not working o kern/155577 emulation [boot] BTX halted after install. Reboot during install o kern/155238 emulation 20 minute time jumps in VirtualBox o kern/155040 emulation [linux] [patch] Linux recvfrom doesn't handle proto fa o kern/153990 emulation [hyper-v]: Will not install into Hyper-V on Server 200 o kern/153887 emulation [linux] Linux emulator not understand STB_GNU_UNIQUE b o kern/153243 emulation [ibcs2] Seg fault whne running COFF binary using iBCS2 o ports/151714 emulation print/acroread9 not usable due to lack of support in t a bin/150262 emulation [patch] truss(1) -f doesn't follow descendants of the a kern/150186 emulation [parallels] [panic] Parallels Desktop: CDROM disconnec o ports/148097 emulation [patch] suggested addition to linux_base-* packages to o ports/148096 emulation emulators/linux_base-* can not be built from ports on o kern/147793 emulation [vmware] [panic] cdrom handling, panic, possible race o kern/146237 emulation [linux] Linux binaries not reading directories mounted f kern/144763 emulation [linux] [panic] Kernel panic when start linux binaries p kern/144584 emulation [linprocfs][patch] bogus values in linprocfs o ports/142837 emulation [patch] emulators/linux_base-* packages fails to insta o kern/140156 emulation [linux] cdparanoia fails to read drive data f kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest s ports/136321 emulation x11-toolkits/linux-pango: please update linux based po o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage s kern/133144 emulation [linux] linuxulator 2.6 crashes with nvidias libGL.so. o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/86619 emulation [linux] linux emulator interacts oddly with cp a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/36952 emulation [patch] [linux] ldd(1) command of linux does not work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 32 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 11:23:35 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 976101065676 for ; Mon, 2 May 2011 11:23:35 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 265C18FC0A for ; Mon, 2 May 2011 11:23:34 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p42BNUjr017187 for ; Mon, 2 May 2011 04:23:30 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DBE9434.1090201@mittelstaedt.us> Date: Mon, 02 May 2011 04:23:32 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> In-Reply-To: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.1 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 11:23:35 -0000 On 5/1/2011 10:54 PM, John wrote: > > -----Original Message----- >> From: Ted Mittelstaedt >> >> On 4/30/2011 7:28 PM, typo W wrote: >>> Hi, I'm brand new to virtualbox, so pardon me in case I made >>> stupid mistakes. I created a FreeBSD guest out of the regular >>> virtualbox port (3.2.12) on FreeBSD 8.2, then timed the copying >>> of a 320MB binary file to another file, which took 4 seconds, ie, >>> 80MB/s. On an identical hardware I created a CentOS guest out of >>> KVM running on CentOS, and the same operation only takes 1 >>> second. On both hosts, the copy takes 1 second. That is, >>> virtualbox slowed the copying to 1/4 speed on my guest FreeBSD. >>> >>> Both hosts are Dell R710, with 6 x 600GB 15K SAS drives forming >>> a RAID6 with R700 controller with 512MB cache. >>> >> >> Try some file copies at the base OS and let us know the results. >> >> I would guess that the FreeBSD hardware RAID device driver for the >> R700 controller isn't using the hardware write caching of the >> controller. When the FreeBSD host OS got the file write call from >> the virtual box it should have issued the write to the disk >> controller and then returned immediately since the write should >> have gone into the hardware cache of the controller. >> >> you can also try playing with the sync/async options in the host >> OS. See the mount command for details. it is kind of pointless to >> do sync writes on a caching hardware controller because the entire >> point of sync writes is to keep the data from being scrambled in a >> crash or if there is sudden power loss - but the cache in the >> hardware array card is more than capable of screwing the >> filesystem if that happens. >> >> Ted >> >> > > On both the FreeBSD host and the CentOS host, the copying only takes > 1 second, as tested before. Actually, the classic "dd" test is > slightly faster on the FreeBSD host than on the CentOS host. > > The storage I chose for the virtualbox guest is a SAS controller. I > found by default it did not enable "Use Host I/O Cache". I just > enabled that and rebooted the guest. Now the copying on the guest > takes 3 seconds. Still, that's clearly slower than 1 second. > > Any other things I can try? I love FreeBSD and hope we can sort this > out. did you try mounting the filesystem that the virtualbox is writing to, async? what is the contents of the freebsd host /etc/fstab? Ted > > Thanks, John > > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To > unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 12:36:12 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21C651065672 for ; Mon, 2 May 2011 12:36:12 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7708FC17 for ; Mon, 2 May 2011 12:36:11 +0000 (UTC) Received: by eyg7 with SMTP id 7so2205604eyg.13 for ; Mon, 02 May 2011 05:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0KNSeALI0XnbHb8FPbREdfTEv8HEi/glsojChMHuL3g=; b=w2z+JLjtmHTWJf9ag7speOz4CeKBhH1Jpll2Dh4JVebP71oBuAtGUjU6+Nvf1/aF8g ED0jA4cWVS2u3mdVwTJvRKG3p7RrkEa7wQVaHdsryyUCT494CC6+hqkAJHdlzY1eWjDD uqnokFtjMU22iWnz8jzz98DZFWLUtwYR9hzns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MBJfkFs27y7LcxLb7vQBoEUo+3wcUm1JQCS8rOMdUaGZ2j4mr5ULvwHy5qJ4bqfHgZ tIkYrBwP8BKzkA21kTyBj6vbbTvE+L28JLK7nDT8xhWS6ZWqmC+SIWIua+v3Y+GjQF15 X17ER4EDXyF8Gd+sVsEG8jZBxr1e9kl/2wBsg= MIME-Version: 1.0 Received: by 10.223.54.213 with SMTP id r21mr946722fag.54.1304338196724; Mon, 02 May 2011 05:09:56 -0700 (PDT) Received: by 10.223.20.145 with HTTP; Mon, 2 May 2011 05:09:56 -0700 (PDT) In-Reply-To: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Mon, 2 May 2011 07:09:56 -0500 Message-ID: From: Adam Vande More To: John Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:36:12 -0000 On Mon, May 2, 2011 at 12:54 AM, John wrote: > On both the FreeBSD host and the CentOS host, the copying only takes 1 > second, as tested before. Actually, the classic "dd" test is slightly > faster on the FreeBSD host than on the CentOS host. > > The storage I chose for the virtualbox guest is a SAS controller. I found > by default it did not enable "Use Host I/O Cache". I just enabled that and > rebooted the guest. Now the copying on the guest takes 3 seconds. Still, > that's clearly slower than 1 second. > > Any other things I can try? I love FreeBSD and hope we can sort this out. > Your FreeBSD Host/guest results seem relatively consistent with what I would expect since VM block io isn't really that great yet, however the results in your Linux VM seems too good to be true. Have you tried powering off the Linux VM immediately after the cp exits and md5'ing the two files? This will insure your writes are completing successfully. Also, it may be this type of operation really is faster on your Linux setup, but is it representative of the primary workload? If not, you'll probably want to arrange some type of benchmark that mimics real world IO flows as hypervisor IO performance varies across workloads(example: it used to be true KVM wasn't very good at concurrent IO, not sure if it's better now). You should also ensure caches are not effecting the outcome of consecutive benchmarks runs. umounting and remounting the file system on your SAS controller is the quickest way to do this, but depending on your setup you may need to reboot. If you do want to test with caching involved, you should discard the initial run from your results. Use something like /usr/bin/time to get consistent results of how long operations took. Ensure each setup is running in a minimal configuration so there is less resource contention. Also single runs are a terrible way benchmark things. You *need* multiple runs to ensure accuracy. ministat(1) is a tool in base to help with this. Here is more detail: http://ivoras.sharanet.org/blog/tree/2009-12-02.using-ministat.html http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023435.html -- Adam Vande More From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 18:45:47 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D674C1065673 for ; Mon, 2 May 2011 18:45:47 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 90AB48FC0C for ; Mon, 2 May 2011 18:45:47 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p42IjgAu018802 for ; Mon, 2 May 2011 11:45:43 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DBEFBD8.8050107@mittelstaedt.us> Date: Mon, 02 May 2011 11:45:44 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 18:45:48 -0000 On 5/2/2011 5:09 AM, Adam Vande More wrote: > On Mon, May 2, 2011 at 12:54 AM, John wrote: > >> On both the FreeBSD host and the CentOS host, the copying only takes 1 >> second, as tested before. Actually, the classic "dd" test is slightly >> faster on the FreeBSD host than on the CentOS host. >> >> The storage I chose for the virtualbox guest is a SAS controller. I found >> by default it did not enable "Use Host I/O Cache". I just enabled that and >> rebooted the guest. Now the copying on the guest takes 3 seconds. Still, >> that's clearly slower than 1 second. >> >> Any other things I can try? I love FreeBSD and hope we can sort this out. >> > > Your FreeBSD Host/guest results seem relatively consistent with what I would > expect since VM block io isn't really that great yet, however the results in > your Linux VM seems too good to be true. We know that Linux likes to run with the condom off on the file system, (async writes) just because it helps them win all the know-nothing benchmark contests in the ragazines out there, and FreeBSD does not because it's users want to have an intact filesystem in case the system crashes or loses power. I'm guessing this is the central issue here. > Have you tried powering off the > Linux VM immediately after the cp exits and md5'ing the two files? This > will insure your writes are completing successfully. > That isn't going to do anything because the VM will take longer than 3 seconds to close and it it's done gracefully then the VM won't close until the writes are all complete. > Also, it may be this type of operation really is faster on your Linux setup, > but is it representative of the primary workload? If not, you'll probably > want to arrange some type of benchmark that mimics real world IO flows as > hypervisor IO performance varies across workloads(example: it used to be > true KVM wasn't very good at concurrent IO, not sure if it's better now). > You should also ensure caches are not effecting the outcome of consecutive > benchmarks runs. umounting and remounting the file system on your SAS > controller is the quickest way to do this, but depending on your setup you > may need to reboot. If you do want to test with caching involved, you > should discard the initial run from your results. Use something like > /usr/bin/time to get consistent results of how long operations took. Ensure > each setup is running in a minimal configuration so there is less resource > contention. > > Also single runs are a terrible way benchmark things. You *need* multiple > runs to ensure accuracy. ministat(1) is a tool in base to help with this. > Here is more detail: > > http://ivoras.sharanet.org/blog/tree/2009-12-02.using-ministat.html > http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023435.html > However that tool doesn't mimic real world behavior, either. The only real way to test is to run both systems in production and see what happens. I would not make a choice of going with one system over another based on a single large file write difference of 2 seconds. We have to assume he's got an application that makes hundreds to thousands of large file writes where this discrepancy would actually make a difference. Ted From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 19:43:40 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7819B106566B for ; Mon, 2 May 2011 19:43:40 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F3B6B8FC17 for ; Mon, 2 May 2011 19:43:39 +0000 (UTC) Received: by fxm11 with SMTP id 11so5616326fxm.13 for ; Mon, 02 May 2011 12:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oIaKAzilSVWKuqFI+7YhRpYiFCFR6gxG6c6I9pKBw38=; b=J1O9CNOqqb5l47p+eRrjeTQx1kzy+4dFqPMCyLVRPlQfvgQdzDNN3RYuOzb2r7OhKj Y0JPHGzyLARCvGcEObcUAzsfNP3fL4asZ1UT5wwMC6I/e408O3jMPhFc9dHATBaBHbJ5 a/E8Mk49+Jwb5y5geyF6xVKwBKUTp284/4548= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fyvyBZCID7vlZukftitSmaHsI1nHfFK2h91+xmofF0CyKeXZYzmlIfSSdSTjsU6aQX C3+U30SQlr07+1nkfWZNvP2CBCWIR6NF32tZ6dqFKgkS75+CyvBbaYqhBar8wXyPQTbs JoMzXpBP/zT9e/05vzw29wCarbPj0xde2OmCs= MIME-Version: 1.0 Received: by 10.223.54.213 with SMTP id r21mr1435225fag.54.1304365418487; Mon, 02 May 2011 12:43:38 -0700 (PDT) Received: by 10.223.20.145 with HTTP; Mon, 2 May 2011 12:43:38 -0700 (PDT) In-Reply-To: <4DBEFBD8.8050107@mittelstaedt.us> References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <4DBEFBD8.8050107@mittelstaedt.us> Date: Mon, 2 May 2011 14:43:38 -0500 Message-ID: From: Adam Vande More To: Ted Mittelstaedt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 19:43:40 -0000 On Mon, May 2, 2011 at 1:45 PM, Ted Mittelstaedt wrote: > On 5/2/2011 5:09 AM, Adam Vande More wrote: > >> On Mon, May 2, 2011 at 12:54 AM, John wrote: >> >> On both the FreeBSD host and the CentOS host, the copying only takes 1 >>> second, as tested before. Actually, the classic "dd" test is slightly >>> faster on the FreeBSD host than on the CentOS host. >>> >>> The storage I chose for the virtualbox guest is a SAS controller. I >>> found >>> by default it did not enable "Use Host I/O Cache". I just enabled that >>> and >>> rebooted the guest. Now the copying on the guest takes 3 seconds. >>> Still, >>> that's clearly slower than 1 second. >>> >>> Any other things I can try? I love FreeBSD and hope we can sort this >>> out. >>> >>> >> Your FreeBSD Host/guest results seem relatively consistent with what I >> would >> expect since VM block io isn't really that great yet, however the results >> in >> your Linux VM seems too good to be true. >> > > We know that Linux likes to run with the condom off on the file system, > (async writes) just because it helps them win all the know-nothing > benchmark contests in the ragazines out there, and FreeBSD does not > because it's users want to have an intact filesystem in case the > system crashes or loses power. I'm guessing this is the central issue > here. > > > Have you tried powering off the >> Linux VM immediately after the cp exits and md5'ing the two files? This >> will insure your writes are completing successfully. >> >> > That isn't going to do anything because the VM will take longer than 3 > seconds to close and it it's done gracefully then the VM won't close until > the writes are all complete. No, this is no correct. You can kill the VM before it has a chance to sync(in Vbox, the poweroff button does this, and the qemu/kvm stop command is not a graceful shutdown either). I haven't actually tested this, but it would seem to be a large bug if doesn't work this way since there are also graceful shutdown options in both hypervisors and the documenation states you may lose data with this option. If nothing else, the real power cord will do the same thing. > http://ivoras.sharanet.org/blog/tree/2009-12-02.using-ministat.html >> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023435.html >> >> > However that tool doesn't mimic real world behavior, either. That tool is for analyzing benchmarks, not running them. > The only > real way to test is to run both systems in production and see what > happens. > Any dev/testing environment I setup or worked with has a method for simulating extremely bad scenarios production might face like 10,000 devices phoning home at once to an aggregation network, with an equally severe load coming from the web frontend. I thought this was pretty common practice. I would not make a choice of going with one system over another based > on a single large file write difference of 2 seconds. We have to > assume he's got an application that makes hundreds to thousands of large > file writes where this discrepancy would actually make a difference. > >From the information given, that's not an assumption I'm comfortable with. OP will have to find his own way on that whether it's something like blogbench or bonnie or "real data" with real data being the best. Agreed that discrepancy surely would make a difference if it's consistent across his normal workload. However, there are many cases where that might not be true. -- Adam Vande More From owner-freebsd-emulation@FreeBSD.ORG Mon May 2 21:30:39 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56569106564A for ; Mon, 2 May 2011 21:30:39 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id D4C398FC1A for ; Mon, 2 May 2011 21:30:38 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p42LUXtB019213; Mon, 2 May 2011 14:30:34 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DBF227A.1000704@mittelstaedt.us> Date: Mon, 02 May 2011 14:30:34 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Adam Vande More References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <4DBEFBD8.8050107@mittelstaedt.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 21:30:39 -0000 On 5/2/2011 12:43 PM, Adam Vande More wrote: > On Mon, May 2, 2011 at 1:45 PM, Ted Mittelstaedt > wrote: > > On 5/2/2011 5:09 AM, Adam Vande More wrote: > > On Mon, May 2, 2011 at 12:54 AM, John > wrote: > > On both the FreeBSD host and the CentOS host, the copying > only takes 1 > second, as tested before. Actually, the classic "dd" test > is slightly > faster on the FreeBSD host than on the CentOS host. > > The storage I chose for the virtualbox guest is a SAS > controller. I found > by default it did not enable "Use Host I/O Cache". I just > enabled that and > rebooted the guest. Now the copying on the guest takes 3 > seconds. Still, > that's clearly slower than 1 second. > > Any other things I can try? I love FreeBSD and hope we can > sort this out. > > > Your FreeBSD Host/guest results seem relatively consistent with > what I would > expect since VM block io isn't really that great yet, however > the results in > your Linux VM seems too good to be true. > > > We know that Linux likes to run with the condom off on the file system, > (async writes) just because it helps them win all the know-nothing > benchmark contests in the ragazines out there, and FreeBSD does not > because it's users want to have an intact filesystem in case the > system crashes or loses power. I'm guessing this is the central issue > here. > > > Have you tried powering off the > Linux VM immediately after the cp exits and md5'ing the two > files? This > will insure your writes are completing successfully. > > > That isn't going to do anything because the VM will take longer than 3 > seconds to close and it it's done gracefully then the VM won't close > until the writes are all complete. > > > No, this is no correct. You can kill the VM before it has a chance to > sync(in Vbox, the poweroff button does this, and the qemu/kvm stop > command is not a graceful shutdown either). that's sync within the VM. Where is the bottleneck taking place? If the bottleneck is hypervisor to host, then the guest to vm write may write all it's data to a memory buffer in the hypervisor that is then slower-writing it to the filesystem. In that case killing the guest without killing the VM manager will allow the buffer to complete emptying since the hypervisor isn't actually being shut down. I haven't actually tested > this, but it would seem to be a large bug if doesn't work this way since > there are also graceful shutdown options in both hypervisors and the > documenation states you may lose data with this option. If nothing > else, the real power cord will do the same thing. > > > http://ivoras.sharanet.org/blog/tree/2009-12-02.using-ministat.html > http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023435.html > > > However that tool doesn't mimic real world behavior, either. > > > That tool is for analyzing benchmarks, not running them. > > The only > real way to test is to run both systems in production and see what > happens. > > > Any dev/testing environment I setup or worked with has a method for > simulating extremely bad scenarios production might face like 10,000 > devices phoning home at once to an aggregation network, with an equally > severe load coming from the web frontend. I thought this was pretty > common practice. > Is his app going to ever face the extremely bad scenario, though? If your server is going to melt down at 10,000 devices phoning home then the difference between FreeBSD and Centos may be that the Centos system lasts 50 milliseconds longer than the FreeBSD system before cascading into an overload. You can spend a lot of time setting up a test environment to simulate a production environment when just running it in production for a while would answer the question. Not to mention that for high-volume apps the iron is always the cheapest part so most admins in that scenario just throw a little more money at the iron. > I would not make a choice of going with one system over another based > on a single large file write difference of 2 seconds. We have to > assume he's got an application that makes hundreds to thousands of large > file writes where this discrepancy would actually make a difference. > > From the information given, that's not an assumption I'm comfortable > with. OP will have to find his own way on that whether it's something > like blogbench or bonnie or "real data" with real data being the best. > Agreed that discrepancy surely would make a difference if it's > consistent across his normal workload. However, there are many cases > where that might not be true. > The lack of further info from the OP makes this more of a speculators discussion than anything else. Ted > -- > Adam Vande More From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 02:39:40 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60D1F1065672 for ; Tue, 3 May 2011 02:39:40 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E0B9F8FC13 for ; Tue, 3 May 2011 02:39:39 +0000 (UTC) Received: by fxm11 with SMTP id 11so5849556fxm.13 for ; Mon, 02 May 2011 19:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f3vfvWRWwAxAF7xN47VcjaylsaMFU9roCEBoNFUXy3w=; b=Cj+7VMhma9AGj8PxDBlwGZsGtuPw0Jof95EQFHtwkRsoDfSj1eQiQcyFxyQDEki1/J BjI7PcoWqPyKFXJ5REpfcHEC52nY5MepejhPVM6W1WDUCWb9bwes0aAtGm5Oxfwq5QMY AYm+9ILS/JM4Try3NRxRLUXhIC36Iu3hvCcxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YzBxgDQ68g7E6LZ5nDJ9bBXceMThVvkmWpbi6QxouSh1NtoM4fxOzHNaiP5rne5HQr N0kpsdziObeaEhB3J3CkRQi/MRMv04y945VqGCcAGnd0JhZ7hmX7D5RdnQ5foFLGMEPT zFyUZENZkQ5wdtebElF69vTJLefMycWZNb65k= MIME-Version: 1.0 Received: by 10.223.127.210 with SMTP id h18mr2600512fas.73.1304390378689; Mon, 02 May 2011 19:39:38 -0700 (PDT) Received: by 10.223.20.145 with HTTP; Mon, 2 May 2011 19:39:38 -0700 (PDT) In-Reply-To: <4DBF227A.1000704@mittelstaedt.us> References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <4DBEFBD8.8050107@mittelstaedt.us> <4DBF227A.1000704@mittelstaedt.us> Date: Mon, 2 May 2011 21:39:38 -0500 Message-ID: From: Adam Vande More To: Ted Mittelstaedt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 02:39:40 -0000 On Mon, May 2, 2011 at 4:30 PM, Ted Mittelstaedt wrote: > that's sync within the VM. Where is the bottleneck taking place? If > the bottleneck is hypervisor to host, then the guest to vm write may write > all it's data to a memory buffer in the hypervisor that is then > slower-writing it to the filesystem. In that case killing the guest without > killing the VM manager will allow the buffer to complete emptying since the > hypervisor isn't actually being shut down. No the bottle neck is the emulated hardware inside the VM process container. This is easy to observe, just start a bound process in the VM and watch top host side. Also the hypervisor uses native host IO driver, there's no reason for it to be slow. Since it's the emulated NIC which is the bottleneck, there is nothing left to issue the write. Further empirical evidence for this can be seen by by watching gstat on VM running with an md or ZVOL backed storage. I already utilize ZVOL's for this so it was pretty easy to confirm no IO occurs when the VM is paused or shutdown. Is his app going to ever face the extremely bad scenario, though? > The point is it should be relatively easy to induce patterns you expect to see in production. If you can't, I would consider that a problem. Testing out theories(performance based or otherwise) on a production system is not a good way to keep the continued faith of your clients when the production system is a mission critical one. Maybe throwing more hardware at a problem is the first line of defense for some companies, unfortunately I don't work for them. Are they hiring? ;) I understand the logic of such an approach and have even argued for it occasionally. Unfortunately payroll is already in the budget, extra hardware is not even if it would be a net savings. -- Adam Vande More From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 02:53:33 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 243C6106566B for ; Tue, 3 May 2011 02:53:33 +0000 (UTC) (envelope-from rnejdl@ringofsaturn.com) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [71.252.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id C6E2B8FC0A for ; Tue, 3 May 2011 02:53:32 +0000 (UTC) Received: from ASSP.nospam (tethys [71.252.219.43]) (authenticated bits=0) by tethys.ringofsaturn.com (8.14.4/8.14.4) with ESMTP id p432rWWd036342 for ; Mon, 2 May 2011 21:53:32 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com ([71.252.219.43] helo=mail.ringofsaturn.com) with IPv4:25 by ASSP.nospam; 2 May 2011 21:53:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 May 2011 21:53:31 -0500 From: Rusty Nejdl To: Mail-Reply-To: In-Reply-To: References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <4DBEFBD8.8050107@mittelstaedt.us> <4DBF227A.1000704@mittelstaedt.us> Message-ID: X-Sender: rnejdl@ringofsaturn.com User-Agent: Roundcube Webmail/0.6-svn X-Assp-Intended-For-IP: 71.252.219.43 X-Assp-Passing: authenticated X-Assp-ID: ASSP.nospam (m-30439-07316) X-Assp-Version: 1.8.5.6(1.0.05) Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 02:53:33 -0000 On Mon, 2 May 2011 21:39:38 -0500, Adam Vande More wrote: > On Mon, May 2, 2011 at 4:30 PM, Ted Mittelstaedt > wrote: > >> that's sync within the VM. Where is the bottleneck taking place? >> If >> the bottleneck is hypervisor to host, then the guest to vm write may >> write >> all it's data to a memory buffer in the hypervisor that is then >> slower-writing it to the filesystem. In that case killing the guest >> without >> killing the VM manager will allow the buffer to complete emptying >> since the >> hypervisor isn't actually being shut down. > > > No the bottle neck is the emulated hardware inside the VM process > container. This is easy to observe, just start a bound process in > the VM > and watch top host side. Also the hypervisor uses native host IO > driver, > there's no reason for it to be slow. Since it's the emulated NIC > which is > the bottleneck, there is nothing left to issue the write. Further > empirical > evidence for this can be seen by by watching gstat on VM running with > an md > or ZVOL backed storage. I already utilize ZVOL's for this so it was > pretty > easy to confirm no IO occurs when the VM is paused or shutdown. > > Is his app going to ever face the extremely bad scenario, though? >> > > The point is it should be relatively easy to induce patterns you > expect to > see in production. If you can't, I would consider that a problem. > Testing > out theories(performance based or otherwise) on a production system > is not a > good way to keep the continued faith of your clients when the > production > system is a mission critical one. Maybe throwing more hardware at a > problem > is the first line of defense for some companies, unfortunately I > don't work > for them. Are they hiring? ;) I understand the logic of such an > approach > and have even argued for it occasionally. Unfortunately payroll is > already > in the budget, extra hardware is not even if it would be a net > savings. I'm going to ask a stupid question... are you using bridging for your emulated NIC? At least, that's how I read what you wrote that you are starved at the NIC side and I saw a vast performance increase switching to bridging. Sincerely, Rusty Nejdl From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 04:02:30 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE60106564A for ; Tue, 3 May 2011 04:02:30 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 362AA8FC13 for ; Tue, 3 May 2011 04:02:29 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p4342NhS021016; Mon, 2 May 2011 21:02:24 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DBF7E50.8050401@mittelstaedt.us> Date: Mon, 02 May 2011 21:02:24 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Adam Vande More References: <10651953.1304315663013.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> <4DBEFBD8.8050107@mittelstaedt.us> <4DBF227A.1000704@mittelstaedt.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 04:02:30 -0000 On 5/2/2011 7:39 PM, Adam Vande More wrote: > On Mon, May 2, 2011 at 4:30 PM, Ted Mittelstaedt > wrote: > > that's sync within the VM. Where is the bottleneck taking place? If > the bottleneck is hypervisor to host, then the guest to vm write may > write all it's data to a memory buffer in the hypervisor that is > then slower-writing it to the filesystem. In that case killing the > guest without killing the VM manager will allow the buffer to > complete emptying since the hypervisor isn't actually being shut down. > > > No the bottle neck is the emulated hardware inside the VM process > container. This is easy to observe, just start a bound process in the > VM and watch top host side. Also the hypervisor uses native host IO > driver, there's no reason for it to be slow. Since it's the emulated > NIC which is the bottleneck, there is nothing left to issue the write. > Further empirical evidence for this can be seen by by watching gstat on > VM running with an md or ZVOL backed storage. I already utilize ZVOL's > for this so it was pretty easy to confirm no IO occurs when the VM is > paused or shutdown. > > Is his app going to ever face the extremely bad scenario, though? > > > The point is it should be relatively easy to induce patterns you expect > to see in production. If you can't, I would consider that a problem. > Testing out theories(performance based or otherwise) on a production > system is not a good way to keep the continued faith of your clients > when the production system is a mission critical one. Maybe throwing > more hardware at a problem is the first line of defense for some > companies, unfortunately I don't work for them. Are they hiring? ;) I > understand the logic of such an approach and have even argued for it > occasionally. Unfortunately payroll is already in the budget, extra > hardware is not even if it would be a net savings. > Most if not all sites I've ever been in that run Windows servers behave in this manner. With most of these sites SOP is to "prove" that the existing hardware is inadequate by loading whatever Windows software that management wants loaded then letting the users on the network scream about it. Then money magically frees itself up when there wasn't any before. Since of course management will never blame the OS for the slowness, always the hardware. Understand I'm not advocating this, just making an observation. Understand that I'm not against testing but I've seen people get so engrossed in spending time constructing test suites that they have ended up wasting a lot of money. I would have to ask, how much time did the OP who started this thread take building 2 systems, a Linux and a BSD system? How much time has he spent trying to get the BSD system to "work as well as the Linux" system? Wouldn't it have been cheaper for him to not spend that time and just put the Linux system into production? Ted From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 06:16:32 2011 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A943F1065670; Tue, 3 May 2011 06:16:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2F18FC0C; Tue, 3 May 2011 06:16:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p436GWRO085075; Tue, 3 May 2011 06:16:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p436GWmi085071; Tue, 3 May 2011 06:16:32 GMT (envelope-from linimon) Date: Tue, 3 May 2011 06:16:32 GMT Message-Id: <201105030616.p436GWmi085071@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-emulation@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/156691: [vmware] [panic] panic when using hard disks as RAW devices within VMWare ESXi 4.1-u1 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 06:16:32 -0000 Old Synopsis: panic when using hard disks as RAW devices within VMWare ESXi 4.1-u1 New Synopsis: [vmware] [panic] panic when using hard disks as RAW devices within VMWare ESXi 4.1-u1 Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 3 06:14:34 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=156691 From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 12:46:18 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E799106566B; Tue, 3 May 2011 12:46:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 48AFA8FC08; Tue, 3 May 2011 12:46:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA03724; Tue, 03 May 2011 15:46:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QHEzW-0003HW-66; Tue, 03 May 2011 15:46:14 +0300 Message-ID: <4DBFF915.3090103@FreeBSD.org> Date: Tue, 03 May 2011 15:46:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Lock References: <4DB72341.7060201@FreeBSD.org> <20110426202349.GA14855@triton8.kn-bremen.de> <4DB7BC6A.7060207@FreeBSD.org> <20110427163047.GA47520@triton8.kn-bremen.de> <7d7a2fab-7c4e-44ce-bdf2-93811c40a4fe@email.android.com> <20110428193351.GA8814@triton8.kn-bremen.de> <68864477@h30.sp.ipt.ru> <20110428220114.00004b22@unknown> <20110428201939.GA16556@triton8.kn-bremen.de> <4DBA4F77.1000409@FreeBSD.org> <20110429212306.GA43822@triton8.kn-bremen.de> In-Reply-To: <20110429212306.GA43822@triton8.kn-bremen.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emulation@FreeBSD.org, HASHI Hiroaki , multimedia@FreeBSD.org Subject: Re: audio/linux-f10-alsa-plugins-oss X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 12:46:18 -0000 on 30/04/2011 00:23 Juergen Lock said the following: > I think now that the port is committed it's the maintainer's call, > so I Cc'd him. :) Cunning :-) -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 16:00:23 2011 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9773E106566C for ; Tue, 3 May 2011 16:00:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0EC8FC0C for ; Tue, 3 May 2011 16:00:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p43G0Nn0050384 for ; Tue, 3 May 2011 16:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p43G0Nqp050381; Tue, 3 May 2011 16:00:23 GMT (envelope-from gnats) Date: Tue, 3 May 2011 16:00:23 GMT Message-Id: <201105031600.p43G0Nqp050381@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: kern/156691: panic when using hard disks as RAW devices within VMWare ESXi 4.1-u1 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:00:23 -0000 The following reply was made to PR kern/156691; it has been noted by GNATS. From: Jaakko Heinonen To: Helmut Schneider Cc: bug-followup@FreeBSD.org Subject: Re: kern/156691: panic when using hard disks as RAW devices within VMWare ESXi 4.1-u1 Date: Tue, 3 May 2011 18:57:48 +0300 On 2011-04-28, Helmut Schneider wrote: > panic: ufs_dirbad: /mnt/da1: bad dir ino 117760 at offset 257: mangled entry I'd say that this panic is result of the corruption and not related to the actual cause. > mpt0: port 0x1400-0x14ff mem > 0xd8820000-0xd883ffff,0xd8800000-0xd881ffff irq 17 at device 16.0 on pci0 > mpt0: [ITHREAD] > mpt0: MPI Version=1.2.0.0 Could you try using a different storage controller (driver) for the disks? > da0 at mpt0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 6.600MB/s transfers (16bit) > da0: Command Queueing enabled > da0: 16384MB (33554432 512 byte sectors: 255H 63S/T 2088C) > da1 at mpt0 bus 0 scbus0 target 1 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 6.600MB/s transfers (16bit) > da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) -- Jaakko From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 18:25:22 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8AD1065672 for ; Tue, 3 May 2011 18:25:22 +0000 (UTC) (envelope-from aqqa11@earthlink.net) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by mx1.freebsd.org (Postfix) with ESMTP id 839C38FC14 for ; Tue, 3 May 2011 18:25:22 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d5WK2XBR8ZfamWEkgwG2Fp0TC+LmolGg1HrkDPH0r7cT7lhzvDP4CM7EEjdg7eQq; h=Message-ID:Date:From:Reply-To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.28] (helo=mswamui-blood.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QHKHi-0005os-7d for freebsd-emulation@freebsd.org; Tue, 03 May 2011 14:25:22 -0400 Received: from 96.242.250.147 by webmail.earthlink.net with HTTP; Tue, 3 May 2011 14:25:21 -0400 Message-ID: <32556218.1304447122068.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Tue, 3 May 2011 14:25:21 -0400 (EDT) From: John Cc: freebsd-emulation@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 2552ff5019365d7e94f5150ab1c16ac02930b881f11d255e91933f0dae449a7a851f6fed1f38d8a9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.28 Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:25:22 -0000 -----Original Message----- >From: Ted Mittelstaedt >Sent: May 3, 2011 12:02 AM >To: Adam Vande More >Cc: freebsd-emulation@freebsd.org >Subject: Re: virtualbox I/O 3 times slower than KVM? > >On 5/2/2011 7:39 PM, Adam Vande More wrote: >> On Mon, May 2, 2011 at 4:30 PM, Ted Mittelstaedt > > wrote: >> >> that's sync within the VM. Where is the bottleneck taking place? If >> the bottleneck is hypervisor to host, then the guest to vm write may >> write all it's data to a memory buffer in the hypervisor that is >> then slower-writing it to the filesystem. In that case killing the >> guest without killing the VM manager will allow the buffer to >> complete emptying since the hypervisor isn't actually being shut down. >> >> >> No the bottle neck is the emulated hardware inside the VM process >> container. This is easy to observe, just start a bound process in the >> VM and watch top host side. Also the hypervisor uses native host IO >> driver, there's no reason for it to be slow. Since it's the emulated >> NIC which is the bottleneck, there is nothing left to issue the write. >> Further empirical evidence for this can be seen by by watching gstat on >> VM running with an md or ZVOL backed storage. I already utilize ZVOL's >> for this so it was pretty easy to confirm no IO occurs when the VM is >> paused or shutdown. >> >> Is his app going to ever face the extremely bad scenario, though? >> >> >> The point is it should be relatively easy to induce patterns you expect >> to see in production. If you can't, I would consider that a problem. >> Testing out theories(performance based or otherwise) on a production >> system is not a good way to keep the continued faith of your clients >> when the production system is a mission critical one. Maybe throwing >> more hardware at a problem is the first line of defense for some >> companies, unfortunately I don't work for them. Are they hiring? ;) I >> understand the logic of such an approach and have even argued for it >> occasionally. Unfortunately payroll is already in the budget, extra >> hardware is not even if it would be a net savings. >> > >Most if not all sites I've ever been in that run Windows servers behave >in this manner. With most of these sites SOP is to "prove" that the >existing hardware is inadequate by loading whatever Windows software >that management wants loaded then letting the users on the network >scream about it. Then money magically frees itself up when there wasn't >any before. Since of course management will never blame the OS for >the slowness, always the hardware. > >Understand I'm not advocating this, just making an observation. > >Understand that I'm not against testing but I've seen people get >so engrossed in spending time constructing test suites that they >have ended up wasting a lot of money. I would have to ask, how much >time did the OP who started this thread take building 2 systems, >a Linux and a BSD system? How much time has he spent trying to get >the BSD system to "work as well as the Linux" system? Wouldn't it >have been cheaper for him to not spend that time and just put the >Linux system into production? > >Ted Thanks a lot for everyone's insights and suggestions. The CentOS on the KVM is a production server, so I took some time to prepare another CentOS on that KVM and did the test as Ted suggested before (for comparison, right now the test freebsd is the only guest on the virtualbox). What I do is to cat the 330MB binary file (XP service pack from Microsoft) 20 times into a single 6.6GB file, "date" before and afterwards, and after the second date finishes, immediately Force power shut down. There are two observations: 1. the time to complete copying into this 6.6GB file were 72s, 44s, 79s in three runs, presumably because there is another production VM on the same host. The average is 65s, so it's about 100MB/s. 2. After immediately power down, I do found the resulting file was less than 6.6GB. So indeed the VM claimed the completion of the copying before it actually did. I then did the same thing on the virtualbox, since I don't want the above premature I/O, I made sure the "Use Host I/O cache" is unchecked for the VM storage. 1. the time to complete copying into this 6.6GB file was 119s and 92s, the average is 105s, so the speed is 62MB/s. 2. after immediately "Reset" the machine, I couldn't boot. Both times it asked me to do fsck for that partition (GPT 2.2T). But after finally powering up, I found the file was also less than 6.6GB both times as well. So looks like virtualbox also suffers caching problem? Or did I do anything wrong? I didn't spend extra time optimizing either the linux or the freebsd, they are both the production systems from centos and freebsd. I just want to have a production quality system without too much customized work. Also, most servers will be mail servers and web servers, with some utilization of database. Granted, copying 6.6GB file is atypical on these servers, but I just want to get an idea of what the server is capable of. I do not know a test software that can benchmark my usage pattern and is readily available on both centos and freebsd. From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 18:34:41 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D75E106566C for ; Tue, 3 May 2011 18:34:41 +0000 (UTC) (envelope-from aqqa11@earthlink.net) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by mx1.freebsd.org (Postfix) with ESMTP id 51F058FC08 for ; Tue, 3 May 2011 18:34:40 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PrjlYNABXTdhpScaN8z8b2P821QJYPpOsYFWB1pYXDCKiuvyOAL2wq54INCON9GR; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.28] (helo=mswamui-blood.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QHKQi-0003BD-BX for freebsd-emulation@freebsd.org; Tue, 03 May 2011 14:34:40 -0400 Received: from 96.242.250.147 by webmail.earthlink.net with HTTP; Tue, 3 May 2011 14:34:39 -0400 Message-ID: <20037078.1304447680252.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Tue, 3 May 2011 14:34:39 -0400 (GMT-04:00) From: John To: freebsd-emulation@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 2552ff5019365d7e94f5150ab1c16ac02930b881f11d255e335d9ba1ca47d2f779cc53d43631f7df350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.28 Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 18:34:41 -0000 -----Original Message----- >From: John >Sent: May 3, 2011 2:25 PM >To: >Cc: freebsd-emulation@freebsd.org >Subject: Re: virtualbox I/O 3 times slower than KVM? > > >-----Original Message----- >>From: Ted Mittelstaedt >>Sent: May 3, 2011 12:02 AM >>To: Adam Vande More >>Cc: freebsd-emulation@freebsd.org >>Subject: Re: virtualbox I/O 3 times slower than KVM? >> >>On 5/2/2011 7:39 PM, Adam Vande More wrote: >>> On Mon, May 2, 2011 at 4:30 PM, Ted Mittelstaedt >> > wrote: >>> >>> that's sync within the VM. Where is the bottleneck taking place? If >>> the bottleneck is hypervisor to host, then the guest to vm write may >>> write all it's data to a memory buffer in the hypervisor that is >>> then slower-writing it to the filesystem. In that case killing the >>> guest without killing the VM manager will allow the buffer to >>> complete emptying since the hypervisor isn't actually being shut down. >>> >>> >>> No the bottle neck is the emulated hardware inside the VM process >>> container. This is easy to observe, just start a bound process in the >>> VM and watch top host side. Also the hypervisor uses native host IO >>> driver, there's no reason for it to be slow. Since it's the emulated >>> NIC which is the bottleneck, there is nothing left to issue the write. >>> Further empirical evidence for this can be seen by by watching gstat on >>> VM running with an md or ZVOL backed storage. I already utilize ZVOL's >>> for this so it was pretty easy to confirm no IO occurs when the VM is >>> paused or shutdown. >>> >>> Is his app going to ever face the extremely bad scenario, though? >>> >>> >>> The point is it should be relatively easy to induce patterns you expect >>> to see in production. If you can't, I would consider that a problem. >>> Testing out theories(performance based or otherwise) on a production >>> system is not a good way to keep the continued faith of your clients >>> when the production system is a mission critical one. Maybe throwing >>> more hardware at a problem is the first line of defense for some >>> companies, unfortunately I don't work for them. Are they hiring? ;) I >>> understand the logic of such an approach and have even argued for it >>> occasionally. Unfortunately payroll is already in the budget, extra >>> hardware is not even if it would be a net savings. >>> >> >>Most if not all sites I've ever been in that run Windows servers behave >>in this manner. With most of these sites SOP is to "prove" that the >>existing hardware is inadequate by loading whatever Windows software >>that management wants loaded then letting the users on the network >>scream about it. Then money magically frees itself up when there wasn't >>any before. Since of course management will never blame the OS for >>the slowness, always the hardware. >> >>Understand I'm not advocating this, just making an observation. >> >>Understand that I'm not against testing but I've seen people get >>so engrossed in spending time constructing test suites that they >>have ended up wasting a lot of money. I would have to ask, how much >>time did the OP who started this thread take building 2 systems, >>a Linux and a BSD system? How much time has he spent trying to get >>the BSD system to "work as well as the Linux" system? Wouldn't it >>have been cheaper for him to not spend that time and just put the >>Linux system into production? >> >>Ted > >Thanks a lot for everyone's insights and suggestions. The CentOS on the KVM is a production server, so I took some time to prepare another CentOS on that KVM and did the test as Ted suggested before (for comparison, right now the test freebsd is the only guest on the virtualbox). > >What I do is to cat the 330MB binary file (XP service pack from Microsoft) 20 times into a single 6.6GB file, "date" before and afterwards, and after the second date finishes, immediately Force power shut down. There are two observations: > >1. the time to complete copying into this 6.6GB file were 72s, 44s, 79s in three runs, presumably because there is another production VM on the same host. The average is 65s, so it's about 100MB/s. >2. After immediately power down, I do found the resulting file was less than 6.6GB. So indeed the VM claimed the completion of the copying before it actually did. > >I then did the same thing on the virtualbox, since I don't want the above premature I/O, I made sure the "Use Host I/O cache" is unchecked for the VM storage. > >1. the time to complete copying into this 6.6GB file was 119s and 92s, the average is 105s, so the speed is 62MB/s. >2. after immediately "Reset" the machine, I couldn't boot. Both times it asked me to do fsck for that partition (GPT 2.2T). But after finally powering up, I found the file was also less than 6.6GB both times as well. > >So looks like virtualbox also suffers caching problem? Or did I do anything wrong? > >I didn't spend extra time optimizing either the linux or the freebsd, they are both the production systems from centos and freebsd. I just want to have a production quality system without too much customized work. > >Also, most servers will be mail servers and web servers, with some utilization of database. Granted, copying 6.6GB file is atypical on these servers, but I just want to get an idea of what the server is capable of. I do not know a test software that can benchmark my usage pattern and is readily available on both centos and freebsd. By the way, I do use bridged networking (it's so much easier to configure bridged network on virtualbox than on kvm). Network on the VM is fine to me. Right now the issue is the I/O. From owner-freebsd-emulation@FreeBSD.ORG Tue May 3 21:59:11 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 608EE1065673; Tue, 3 May 2011 21:59:11 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id F1A208FC19; Tue, 3 May 2011 21:59:10 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 162B81E002C4; Tue, 3 May 2011 23:59:09 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p43LugEW027916; Tue, 3 May 2011 23:56:42 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p43LugJc027915; Tue, 3 May 2011 23:56:42 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 3 May 2011 23:56:42 +0200 To: freebsd-emulation@FreeBSD.org, freebsd-multimedia@FreeBSD.org Message-ID: <20110503215642.GA26299@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ae@FreeBSD.org, netchild@FreeBSD.org, hselasky@FreeBSD.org, avg@FreeBSD.org, kwm@FreeBSD.org Subject: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 21:59:11 -0000 Hi! I somehow thought my linux-v4l2-8-test.patch would also apply on 8.2 but of course it doesn't so I now also made q&d versions for that version: http://people.freebsd.org/~nox/dvb/linux-v4l2-8.2-test.patch and the same with Linux 2.6.17 videodev2.h: http://people.freebsd.org/~nox/dvb/linux-v4l2-2.6.17-8.2-test.patch And I also don't want to keep back ae@'s version which builds as a seperate kld the way I did it for the Linuxolator dvb handler that is now in ports as multimedia/linux_dvbwrapper-kmod: http://people.freebsd.org/~ae/linux_v4l2_kld.tgz Maybe we should turn this into a port too for easy user installation until the patches get committed and for people on (current) releases? (See http://people.freebsd.org/~nox/dvb/ for the others versions.) I now tested skype 2.1.0.81 on 8.2 with the above patch and avg@'s sys/dev/sound/pcm/dsp.c one-line patch [1], and found sound doesn't work when running skype from nfs without locking (wtf!), after extracting the skype tarball [2] locally it started working. I installed these ports: multimedia/webcamd net/skype (for the deps [3]) audio/linux-f10-alsa-plugins-oss (if you use the default /compat/linux/etc/asound.conf don't forget to switch skype's audio input/outputs from `default' to `oss', and if your mic isn't on the default soundcard you also need to add that to the Linux config [4] ^ and select it in skype) audio/alsa-plugins (I already had it installed among other things, might not actually be needed) dns/linux-f10-libasyncns multimedia/linux-f10-libv4l (for the Linux v4l2convert.so that my cam needs) And again I ran skype out of the extracted tarball: LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so ./skype_static-2.1.0.81/skype --resources=$PWD/skype_static-2.1.0.81 (I also tested the latest beta [5] using a pcbsd 9.0 liveusb snapshot but it still didn't want to work for me, something about kwm@'s setup must really be `special', he's the only one I know of that has it working...) Enjoy, :) Juergen [1] http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-April/012024.html [2] http://download.skype.com/linux/skype_static-2.1.0.81.tar.bz2 [3] make all-depends-list in net/skype's port dir gives: /usr/ports/emulators/linux_base-f10 /usr/ports/audio/linux-f10-alsa-lib /usr/ports/graphics/linux-dri74 /usr/ports/textproc/linux-f10-expat /usr/ports/x11-fonts/linux-f10-fontconfig /usr/ports/devel/linux-f10-libsigc++20 /usr/ports/x11/linux-f10-xorg-libs /usr/ports/archivers/rpm /usr/ports/devel/gmake /usr/ports/devel/automake14 /usr/ports/devel/autoconf213 /usr/ports/devel/libtool /usr/ports/devel/popt /usr/ports/devel/gettext /usr/ports/lang/perl5.10 /usr/ports/devel/autoconf /usr/ports/devel/automake-wrapper /usr/ports/devel/m4 /usr/ports/devel/autoconf-wrapper /usr/ports/converters/libiconv /usr/ports/misc/help2man /usr/ports/devel/p5-Locale-gettext [4] example /compat/linux/etc/alsa/pcm/pcm-oss.conf entries for a mic on /dev/dsp4: ---snip------ pcm.oss4 { type oss device /dev/dsp4 hint { description "Open Sound System" } } ctl.oss4 { type oss device /dev/mixer4 hint { description "Open Sound System" } } ---snip------ [5] http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-April/012005.html From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 04:48:48 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBD7106564A for ; Wed, 4 May 2011 04:48:48 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 580ED8FC17 for ; Wed, 4 May 2011 04:48:47 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p444mfYQ026859 for ; Tue, 3 May 2011 21:48:41 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DC0DAA8.8080607@mittelstaedt.us> Date: Tue, 03 May 2011 21:48:40 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <32556218.1304447122068.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> In-Reply-To: <32556218.1304447122068.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 04:48:48 -0000 On 5/3/2011 11:25 AM, John wrote: > > -----Original Message----- >> From: Ted Mittelstaedt Sent: May 3, 2011 >> 12:02 AM To: Adam Vande More Cc: >> freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times >> slower than KVM? >> >> On 5/2/2011 7:39 PM, Adam Vande More wrote: >>> On Mon, May 2, 2011 at 4:30 PM, Ted >>> Mittelstaedt> >>> wrote: >>> >>> that's sync within the VM. Where is the bottleneck taking place? >>> If the bottleneck is hypervisor to host, then the guest to vm >>> write may write all it's data to a memory buffer in the >>> hypervisor that is then slower-writing it to the filesystem. In >>> that case killing the guest without killing the VM manager will >>> allow the buffer to complete emptying since the hypervisor isn't >>> actually being shut down. >>> >>> >>> No the bottle neck is the emulated hardware inside the VM >>> process container. This is easy to observe, just start a bound >>> process in the VM and watch top host side. Also the hypervisor >>> uses native host IO driver, there's no reason for it to be slow. >>> Since it's the emulated NIC which is the bottleneck, there is >>> nothing left to issue the write. Further empirical evidence for >>> this can be seen by by watching gstat on VM running with an md or >>> ZVOL backed storage. I already utilize ZVOL's for this so it was >>> pretty easy to confirm no IO occurs when the VM is paused or >>> shutdown. >>> >>> Is his app going to ever face the extremely bad scenario, >>> though? >>> >>> >>> The point is it should be relatively easy to induce patterns you >>> expect to see in production. If you can't, I would consider that >>> a problem. Testing out theories(performance based or otherwise) >>> on a production system is not a good way to keep the continued >>> faith of your clients when the production system is a mission >>> critical one. Maybe throwing more hardware at a problem is the >>> first line of defense for some companies, unfortunately I don't >>> work for them. Are they hiring? ;) I understand the logic of >>> such an approach and have even argued for it occasionally. >>> Unfortunately payroll is already in the budget, extra hardware is >>> not even if it would be a net savings. >>> >> >> Most if not all sites I've ever been in that run Windows servers >> behave in this manner. With most of these sites SOP is to "prove" >> that the existing hardware is inadequate by loading whatever >> Windows software that management wants loaded then letting the >> users on the network scream about it. Then money magically frees >> itself up when there wasn't any before. Since of course management >> will never blame the OS for the slowness, always the hardware. >> >> Understand I'm not advocating this, just making an observation. >> >> Understand that I'm not against testing but I've seen people get so >> engrossed in spending time constructing test suites that they have >> ended up wasting a lot of money. I would have to ask, how much >> time did the OP who started this thread take building 2 systems, a >> Linux and a BSD system? How much time has he spent trying to get >> the BSD system to "work as well as the Linux" system? Wouldn't it >> have been cheaper for him to not spend that time and just put the >> Linux system into production? >> >> Ted > > Thanks a lot for everyone's insights and suggestions. The CentOS on > the KVM is a production server, so I took some time to prepare > another CentOS on that KVM and did the test as Ted suggested before > (for comparison, right now the test freebsd is the only guest on the > virtualbox). > > What I do is to cat the 330MB binary file (XP service pack from > Microsoft) 20 times into a single 6.6GB file, "date" before and > afterwards, and after the second date finishes, immediately Force > power shut down. There are two observations: > > 1. the time to complete copying into this 6.6GB file were 72s, 44s, > 79s in three runs, presumably because there is another production VM > on the same host. The average is 65s, so it's about 100MB/s. 2. > After immediately power down, I do found the resulting file was less > than 6.6GB. So indeed the VM claimed the completion of the copying > before it actually did. > For clarity, what your saying is the CentOS guest OS claimed the copy had completed before it actually did, correct? This is consistent with async-mounted filesystems which I believe is the default under CentOS. Your guest is mounting it's own filesystem inside the VM async mount. So when the copy completes and you get back to the shell prompt on the guest, a memory buffer in the guest OS is still copying the last bits of the file to the disk. > I then did the same thing on the virtualbox, since I don't want the > above premature I/O, I made sure the "Use Host I/O cache" is > unchecked for the VM storage. > That setting isn't going to change how the guest async-mounts it's filesystems. All it does is force the hypervisor to not use some caching that the hypervisor is provided with by the host OS. > 1. the time to complete copying into this 6.6GB file was 119s and > 92s, the average is 105s, so the speed is 62MB/s. 2. after > immediately "Reset" the machine, I couldn't boot. Both times it > asked me to do fsck for that partition (GPT 2.2T). But after finally > powering up, I found the file was also less than 6.6GB both times as > well. > I would imagine this would happen. > So looks like virtualbox also suffers caching problem? Or did I do > anything wrong? > There isn't a "caching problem" As we have said on this forum the speed that the actual write is happening is the same under the FreeBSD guest and the CentOS guest. The only difference is the FreeBSD guest is sync-mounting it's filesystem within the virtual machine and the CentOS guest is async-mounting it's filesystem within the virtual machine. Async mount is always faster for writes because what is actually going on is that the write goes to a memory buffer then the OS completes the write "behind the scenes" In many cases when the data in a file is rapidly changing, the write may never go to disk at all, if the OS sees successive writes to the same part of the file it will simply make the writes to the memory buffer then get around to updating the disk when it feels like. > I didn't spend extra time optimizing either the linux or the freebsd, > they are both the production systems from centos and freebsd. I just > want to have a production quality system without too much customized > work. > > Also, most servers will be mail servers and web servers, with some > utilization of database. Granted, copying 6.6GB file is atypical on > these servers, but I just want to get an idea of what the server is > capable of. I do not know a test software that can benchmark my > usage pattern and is readily available on both centos and freebsd. > What it really sounds like to me is that your just not understanding the difference in how the filesystem is mounted. For starters you have your host OS which the hypervisor is running on. You have a large file on that host which comprises the VM, either freeBSD or CentOS. When the FreeBSD or CentOS guest is making it's writes it is making them into that large file. if the host has that file sync-mounted then it will slow file access by the hypervisor to that file. And then you have the guest OSes which themselves have their own memory buffers and mount chunks of that file as their filesystems. They can mount these chunks sync or async. If they mount them async then it makes access to those chunks faster also. There is a tradeoff here. If you sync-mount a filesystem then if the operating system halts or crashes then there is usually little to no file system damage. But, access to the disk will be slowest. If you async mount a filesystem then if the operating system crashes then you will have a lot of garbage and file corruption. But, access will be the fastest. A very common configuration for a mailserver is when your partitioning the filesystem to create the usual /, swap, /usr, /tmp, & /var - then create an additional /home and "mail". Then you either mount "mail" on /var/mail or you mount it on /mail and softlink /var/mail to /mail. Then you setup /tmp, /home, and /mail or /var/mail as async mount and everything else sync mount, and softlink /var/spool to /tmp. That way if the mailserver reboots or crashes then the program files are generally not affected even if the e-mail is scotched, yet you get the fastest possible disk performance. If a partition is so far gone that it cannot even be repaired by fsck then you can just newfs it and start over. It is also a lot easier to create a dump/restore back up scheme, too. With CentOS/Linux it's a bit different because that OS mounts the entire disk on / and creates subdirectories for everything. That is one of the (many) reasons I don't ever use Linux for mailservers, you do not have the same kind of fine-grained control. But you can create multiple partitions on CentOS, too. Also, the fact is that the FreeBSD filesystem and OS has been heavily optimized and if the mailserver isn't that busy you don't need to bother async mounting any of it's partitions, because the system will simply spawn more processes. You got to think of it this way, for example with a mailserver let's say sync mounting causes each piece of e-mail to spend 15 ms in disk access and let's say async mounting cuts that to 5ms - well if the mailserver normally runs at about 10 simultaneous sendmail instances under async mounting then it will run 30 instances under sync mounting at the same throughput - and with each instance only taking 100MB of ram, you can toss a couple extra GB of ram in the server and forget about it. Ted _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To > unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 05:34:51 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0D20106566B for ; Wed, 4 May 2011 05:34:51 +0000 (UTC) (envelope-from aqqa11@earthlink.net) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by mx1.freebsd.org (Postfix) with ESMTP id 665B38FC0A for ; Wed, 4 May 2011 05:34:51 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VAdH7g1vg/SAMxnv88Y8pzXV0shzrzfs7HzIyDDF7u38o6qkuyBsB4ZnGjAcMvKt; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.28] (helo=mswamui-blood.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QHUja-00051Y-Hi for freebsd-emulation@freebsd.org; Wed, 04 May 2011 01:34:50 -0400 Received: from 96.242.250.147 by webmail.earthlink.net with HTTP; Wed, 4 May 2011 01:34:50 -0400 Message-ID: <32257637.1304487290435.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Wed, 4 May 2011 01:34:50 -0400 (EDT) From: John To: freebsd-emulation@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 2552ff5019365d7e94f5150ab1c16ac02930b881f11d255ec014827934dc6490d65fdab053c5788b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.28 Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 05:34:51 -0000 -----Original Message----- >From: Ted Mittelstaedt >Sent: May 4, 2011 12:48 AM >To: freebsd-emulation@freebsd.org >Subject: Re: virtualbox I/O 3 times slower than KVM? > >On 5/3/2011 11:25 AM, John wrote: >> >> -----Original Message----- >>> From: Ted Mittelstaedt Sent: May 3, 2011 >>> 12:02 AM To: Adam Vande More Cc: >>> freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times >>> slower than KVM? >>> >>> On 5/2/2011 7:39 PM, Adam Vande More wrote: >>>> On Mon, May 2, 2011 at 4:30 PM, Ted >>>> Mittelstaedt> >>>> wrote: >>>> >>>> that's sync within the VM. Where is the bottleneck taking place? >>>> If the bottleneck is hypervisor to host, then the guest to vm >>>> write may write all it's data to a memory buffer in the >>>> hypervisor that is then slower-writing it to the filesystem. In >>>> that case killing the guest without killing the VM manager will >>>> allow the buffer to complete emptying since the hypervisor isn't >>>> actually being shut down. >>>> >>>> >>>> No the bottle neck is the emulated hardware inside the VM >>>> process container. This is easy to observe, just start a bound >>>> process in the VM and watch top host side. Also the hypervisor >>>> uses native host IO driver, there's no reason for it to be slow. >>>> Since it's the emulated NIC which is the bottleneck, there is >>>> nothing left to issue the write. Further empirical evidence for >>>> this can be seen by by watching gstat on VM running with an md or >>>> ZVOL backed storage. I already utilize ZVOL's for this so it was >>>> pretty easy to confirm no IO occurs when the VM is paused or >>>> shutdown. >>>> >>>> Is his app going to ever face the extremely bad scenario, >>>> though? >>>> >>>> >>>> The point is it should be relatively easy to induce patterns you >>>> expect to see in production. If you can't, I would consider that >>>> a problem. Testing out theories(performance based or otherwise) >>>> on a production system is not a good way to keep the continued >>>> faith of your clients when the production system is a mission >>>> critical one. Maybe throwing more hardware at a problem is the >>>> first line of defense for some companies, unfortunately I don't >>>> work for them. Are they hiring? ;) I understand the logic of >>>> such an approach and have even argued for it occasionally. >>>> Unfortunately payroll is already in the budget, extra hardware is >>>> not even if it would be a net savings. >>>> >>> >>> Most if not all sites I've ever been in that run Windows servers >>> behave in this manner. With most of these sites SOP is to "prove" >>> that the existing hardware is inadequate by loading whatever >>> Windows software that management wants loaded then letting the >>> users on the network scream about it. Then money magically frees >>> itself up when there wasn't any before. Since of course management >>> will never blame the OS for the slowness, always the hardware. >>> >>> Understand I'm not advocating this, just making an observation. >>> >>> Understand that I'm not against testing but I've seen people get so >>> engrossed in spending time constructing test suites that they have >>> ended up wasting a lot of money. I would have to ask, how much >>> time did the OP who started this thread take building 2 systems, a >>> Linux and a BSD system? How much time has he spent trying to get >>> the BSD system to "work as well as the Linux" system? Wouldn't it >>> have been cheaper for him to not spend that time and just put the >>> Linux system into production? >>> >>> Ted >> >> Thanks a lot for everyone's insights and suggestions. The CentOS on >> the KVM is a production server, so I took some time to prepare >> another CentOS on that KVM and did the test as Ted suggested before >> (for comparison, right now the test freebsd is the only guest on the >> virtualbox). >> >> What I do is to cat the 330MB binary file (XP service pack from >> Microsoft) 20 times into a single 6.6GB file, "date" before and >> afterwards, and after the second date finishes, immediately Force >> power shut down. There are two observations: >> >> 1. the time to complete copying into this 6.6GB file were 72s, 44s, >> 79s in three runs, presumably because there is another production VM >> on the same host. The average is 65s, so it's about 100MB/s. 2. >> After immediately power down, I do found the resulting file was less >> than 6.6GB. So indeed the VM claimed the completion of the copying >> before it actually did. >> > >For clarity, what your saying is the CentOS guest OS claimed the copy >had completed before it actually did, correct? This is consistent with >async-mounted filesystems which I believe is the default under CentOS. >Your guest is mounting it's own filesystem inside the VM async mount. >So when the copy completes and you get back to the shell prompt on the >guest, a memory buffer in the guest OS is still copying the last bits of >the file to the disk. > >> I then did the same thing on the virtualbox, since I don't want the >> above premature I/O, I made sure the "Use Host I/O cache" is >> unchecked for the VM storage. >> > >That setting isn't going to change how the guest async-mounts it's >filesystems. All it does is force the hypervisor to not use some >caching that the hypervisor is provided with by the host OS. > >> 1. the time to complete copying into this 6.6GB file was 119s and >> 92s, the average is 105s, so the speed is 62MB/s. 2. after >> immediately "Reset" the machine, I couldn't boot. Both times it >> asked me to do fsck for that partition (GPT 2.2T). But after finally >> powering up, I found the file was also less than 6.6GB both times as >> well. >> > >I would imagine this would happen. > >> So looks like virtualbox also suffers caching problem? Or did I do >> anything wrong? >> > >There isn't a "caching problem" As we have said on this forum the >speed that the actual write is happening is the same under the FreeBSD >guest and the CentOS guest. The only difference is the FreeBSD guest >is sync-mounting it's filesystem within the virtual machine and the >CentOS guest is async-mounting it's filesystem within the virtual machine. > >Async mount is always faster for writes because what is actually going >on is that the write goes to a memory buffer then the OS completes the >write "behind the scenes" In many cases when the data in a file is >rapidly changing, the write may never go to disk at all, if the OS sees >successive writes to the same part of the file it will simply make the >writes to the memory buffer then get around to updating the disk when >it feels like. > >> I didn't spend extra time optimizing either the linux or the freebsd, >> they are both the production systems from centos and freebsd. I just >> want to have a production quality system without too much customized >> work. >> >> Also, most servers will be mail servers and web servers, with some >> utilization of database. Granted, copying 6.6GB file is atypical on >> these servers, but I just want to get an idea of what the server is >> capable of. I do not know a test software that can benchmark my >> usage pattern and is readily available on both centos and freebsd. >> > >What it really sounds like to me is that your just not understanding >the difference in how the filesystem is mounted. For starters you >have your host OS which the hypervisor is running on. You have a large >file on that host which comprises the VM, either freeBSD or CentOS. >When the FreeBSD or CentOS guest is making it's writes it is making >them into that large file. if the host has that file sync-mounted >then it will slow file access by the hypervisor to that file. > >And then you have the guest OSes which themselves have their own >memory buffers and mount chunks of that file as their filesystems. >They can mount these chunks sync or async. If they mount them async >then it makes access to those chunks faster also. > >There is a tradeoff here. If you sync-mount a filesystem then if the >operating system halts or crashes then there is usually little to no >file system damage. But, access to the disk will be slowest. If you >async mount a filesystem then if the operating system crashes then >you will have a lot of garbage and file corruption. But, access will >be the fastest. > >A very common configuration for a mailserver is when your partitioning >the filesystem to create the usual /, swap, /usr, /tmp, & /var - then >create an additional /home and "mail". Then you either mount "mail" on >/var/mail or you mount it on /mail and softlink /var/mail to /mail. >Then you setup /tmp, /home, and /mail or /var/mail as async mount and >everything else sync mount, and softlink /var/spool to /tmp. > >That way if the mailserver reboots or crashes then the program files >are generally not affected even if the e-mail is scotched, yet you >get the fastest possible disk performance. If a partition is so far >gone that it cannot even be repaired by fsck then you can just >newfs it and start over. It is also a lot easier to >create a dump/restore back up scheme, too. > >With CentOS/Linux it's a bit different because that OS mounts the >entire disk on / and creates subdirectories for everything. That is >one of the (many) reasons I don't ever use Linux for mailservers, >you do not have the same kind of fine-grained control. But you can >create multiple partitions on CentOS, too. > >Also, the fact is that the FreeBSD filesystem and OS has been heavily >optimized and if the mailserver isn't that busy you don't need to >bother async mounting any of it's partitions, because the system >will simply spawn more processes. You got to think of it this way, >for example with a mailserver let's say sync mounting causes each >piece of e-mail to spend 15 ms in disk access and let's say async >mounting cuts that to 5ms - well if the mailserver normally runs >at about 10 simultaneous sendmail instances under async mounting then >it will run 30 instances under sync mounting at the same throughput - >and with each instance only taking 100MB of ram, you can toss a couple >extra GB of ram in the server and forget about it. > >Ted > Hi Ted, Thanks for taking time to explain this. I'm so sorry I didn't pay attention to this (a)sync mounting options before. Are you talking about these options in the /etc/fstab? I just checked I didn't give any option here (other than 'sw'), for all disk partitions on both the FreeBSD virtualbox host and guest. And the mount manpage said then by default it's sync mounting. Does that mean my FreeBSD guest already sync mounted? Then why it also prematurely declared completion of the writing and couldn't boot? (At the same time, I did confirm that on CentOS the default mount option includes "async".) From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 06:14:36 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669F91065672 for ; Wed, 4 May 2011 06:14:36 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id EB20D8FC13 for ; Wed, 4 May 2011 06:14:35 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p446ETeS027687 for ; Tue, 3 May 2011 23:14:29 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DC0EEC4.8030507@mittelstaedt.us> Date: Tue, 03 May 2011 23:14:28 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <32257637.1304487290435.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> In-Reply-To: <32257637.1304487290435.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:14:36 -0000 On 5/3/2011 10:34 PM, John wrote: > > > > -----Original Message----- >> From: Ted Mittelstaedt Sent: May 4, 2011 >> 12:48 AM To: freebsd-emulation@freebsd.org Subject: Re: virtualbox >> I/O 3 times slower than KVM? >> >> On 5/3/2011 11:25 AM, John wrote: >>> >>> -----Original Message----- >>>> From: Ted Mittelstaedt Sent: May 3, >>>> 2011 12:02 AM To: Adam Vande More Cc: >>>> freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 >>>> times slower than KVM? >>>> >>>> On 5/2/2011 7:39 PM, Adam Vande More wrote: >>>>> On Mon, May 2, 2011 at 4:30 PM, Ted >>>>> Mittelstaedt> >>>>> >>>>> wrote: >>>>> >>>>> that's sync within the VM. Where is the bottleneck taking >>>>> place? If the bottleneck is hypervisor to host, then the >>>>> guest to vm write may write all it's data to a memory buffer >>>>> in the hypervisor that is then slower-writing it to the >>>>> filesystem. In that case killing the guest without killing >>>>> the VM manager will allow the buffer to complete emptying >>>>> since the hypervisor isn't actually being shut down. >>>>> >>>>> >>>>> No the bottle neck is the emulated hardware inside the VM >>>>> process container. This is easy to observe, just start a >>>>> bound process in the VM and watch top host side. Also the >>>>> hypervisor uses native host IO driver, there's no reason for >>>>> it to be slow. Since it's the emulated NIC which is the >>>>> bottleneck, there is nothing left to issue the write. Further >>>>> empirical evidence for this can be seen by by watching gstat >>>>> on VM running with an md or ZVOL backed storage. I already >>>>> utilize ZVOL's for this so it was pretty easy to confirm no >>>>> IO occurs when the VM is paused or shutdown. >>>>> >>>>> Is his app going to ever face the extremely bad scenario, >>>>> though? >>>>> >>>>> >>>>> The point is it should be relatively easy to induce patterns >>>>> you expect to see in production. If you can't, I would >>>>> consider that a problem. Testing out theories(performance >>>>> based or otherwise) on a production system is not a good way >>>>> to keep the continued faith of your clients when the >>>>> production system is a mission critical one. Maybe throwing >>>>> more hardware at a problem is the first line of defense for >>>>> some companies, unfortunately I don't work for them. Are >>>>> they hiring? ;) I understand the logic of such an approach >>>>> and have even argued for it occasionally. Unfortunately >>>>> payroll is already in the budget, extra hardware is not even >>>>> if it would be a net savings. >>>>> >>>> >>>> Most if not all sites I've ever been in that run Windows >>>> servers behave in this manner. With most of these sites SOP is >>>> to "prove" that the existing hardware is inadequate by loading >>>> whatever Windows software that management wants loaded then >>>> letting the users on the network scream about it. Then money >>>> magically frees itself up when there wasn't any before. Since >>>> of course management will never blame the OS for the slowness, >>>> always the hardware. >>>> >>>> Understand I'm not advocating this, just making an >>>> observation. >>>> >>>> Understand that I'm not against testing but I've seen people >>>> get so engrossed in spending time constructing test suites that >>>> they have ended up wasting a lot of money. I would have to >>>> ask, how much time did the OP who started this thread take >>>> building 2 systems, a Linux and a BSD system? How much time >>>> has he spent trying to get the BSD system to "work as well as >>>> the Linux" system? Wouldn't it have been cheaper for him to >>>> not spend that time and just put the Linux system into >>>> production? >>>> >>>> Ted >>> >>> Thanks a lot for everyone's insights and suggestions. The CentOS >>> on the KVM is a production server, so I took some time to >>> prepare another CentOS on that KVM and did the test as Ted >>> suggested before (for comparison, right now the test freebsd is >>> the only guest on the virtualbox). >>> >>> What I do is to cat the 330MB binary file (XP service pack from >>> Microsoft) 20 times into a single 6.6GB file, "date" before and >>> afterwards, and after the second date finishes, immediately >>> Force power shut down. There are two observations: >>> >>> 1. the time to complete copying into this 6.6GB file were 72s, >>> 44s, 79s in three runs, presumably because there is another >>> production VM on the same host. The average is 65s, so it's >>> about 100MB/s. 2. After immediately power down, I do found the >>> resulting file was less than 6.6GB. So indeed the VM claimed the >>> completion of the copying before it actually did. >>> >> >> For clarity, what your saying is the CentOS guest OS claimed the >> copy had completed before it actually did, correct? This is >> consistent with async-mounted filesystems which I believe is the >> default under CentOS. Your guest is mounting it's own filesystem >> inside the VM async mount. So when the copy completes and you get >> back to the shell prompt on the guest, a memory buffer in the guest >> OS is still copying the last bits of the file to the disk. >> >>> I then did the same thing on the virtualbox, since I don't want >>> the above premature I/O, I made sure the "Use Host I/O cache" is >>> unchecked for the VM storage. >>> >> >> That setting isn't going to change how the guest async-mounts it's >> filesystems. All it does is force the hypervisor to not use some >> caching that the hypervisor is provided with by the host OS. >> >>> 1. the time to complete copying into this 6.6GB file was 119s >>> and 92s, the average is 105s, so the speed is 62MB/s. 2. after >>> immediately "Reset" the machine, I couldn't boot. Both times it >>> asked me to do fsck for that partition (GPT 2.2T). But after >>> finally powering up, I found the file was also less than 6.6GB >>> both times as well. >>> >> >> I would imagine this would happen. >> >>> So looks like virtualbox also suffers caching problem? Or did I >>> do anything wrong? >>> >> >> There isn't a "caching problem" As we have said on this forum the >> speed that the actual write is happening is the same under the >> FreeBSD guest and the CentOS guest. The only difference is the >> FreeBSD guest is sync-mounting it's filesystem within the virtual >> machine and the CentOS guest is async-mounting it's filesystem >> within the virtual machine. >> >> Async mount is always faster for writes because what is actually >> going on is that the write goes to a memory buffer then the OS >> completes the write "behind the scenes" In many cases when the >> data in a file is rapidly changing, the write may never go to disk >> at all, if the OS sees successive writes to the same part of the >> file it will simply make the writes to the memory buffer then get >> around to updating the disk when it feels like. >> >>> I didn't spend extra time optimizing either the linux or the >>> freebsd, they are both the production systems from centos and >>> freebsd. I just want to have a production quality system without >>> too much customized work. >>> >>> Also, most servers will be mail servers and web servers, with >>> some utilization of database. Granted, copying 6.6GB file is >>> atypical on these servers, but I just want to get an idea of what >>> the server is capable of. I do not know a test software that can >>> benchmark my usage pattern and is readily available on both >>> centos and freebsd. >>> >> >> What it really sounds like to me is that your just not >> understanding the difference in how the filesystem is mounted. For >> starters you have your host OS which the hypervisor is running on. >> You have a large file on that host which comprises the VM, either >> freeBSD or CentOS. When the FreeBSD or CentOS guest is making it's >> writes it is making them into that large file. if the host has >> that file sync-mounted then it will slow file access by the >> hypervisor to that file. >> >> And then you have the guest OSes which themselves have their own >> memory buffers and mount chunks of that file as their filesystems. >> They can mount these chunks sync or async. If they mount them >> async then it makes access to those chunks faster also. >> >> There is a tradeoff here. If you sync-mount a filesystem then if >> the operating system halts or crashes then there is usually little >> to no file system damage. But, access to the disk will be slowest. >> If you async mount a filesystem then if the operating system >> crashes then you will have a lot of garbage and file corruption. >> But, access will be the fastest. >> >> A very common configuration for a mailserver is when your >> partitioning the filesystem to create the usual /, swap, /usr, >> /tmp,& /var - then create an additional /home and "mail". Then >> you either mount "mail" on /var/mail or you mount it on /mail and >> softlink /var/mail to /mail. Then you setup /tmp, /home, and /mail >> or /var/mail as async mount and everything else sync mount, and >> softlink /var/spool to /tmp. >> >> That way if the mailserver reboots or crashes then the program >> files are generally not affected even if the e-mail is scotched, >> yet you get the fastest possible disk performance. If a partition >> is so far gone that it cannot even be repaired by fsck then you can >> just newfs it and start over. It is also a lot easier to create a >> dump/restore back up scheme, too. >> >> With CentOS/Linux it's a bit different because that OS mounts the >> entire disk on / and creates subdirectories for everything. That >> is one of the (many) reasons I don't ever use Linux for >> mailservers, you do not have the same kind of fine-grained control. >> But you can create multiple partitions on CentOS, too. >> >> Also, the fact is that the FreeBSD filesystem and OS has been >> heavily optimized and if the mailserver isn't that busy you don't >> need to bother async mounting any of it's partitions, because the >> system will simply spawn more processes. You got to think of it >> this way, for example with a mailserver let's say sync mounting >> causes each piece of e-mail to spend 15 ms in disk access and let's >> say async mounting cuts that to 5ms - well if the mailserver >> normally runs at about 10 simultaneous sendmail instances under >> async mounting then it will run 30 instances under sync mounting at >> the same throughput - and with each instance only taking 100MB of >> ram, you can toss a couple extra GB of ram in the server and forget >> about it. >> >> Ted >> > > Hi Ted, > > Thanks for taking time to explain this. I'm so sorry I didn't pay > attention to this (a)sync mounting options before. Are you talking > about these options in the /etc/fstab? yes > I just checked I didn't give > any option here (other than 'sw'), for all disk partitions on both > the FreeBSD virtualbox host and guest. And the mount manpage said > then by default it's sync mounting. yes. the absense of the keyword "async" means it's sync mounted. > Does that mean my FreeBSD guest > already sync mounted? it means your guest has mounted it's filesystems sync. So what is happening is the FreeBSD guest virtual OS makes it's write sync, and is getting told by the hypervisor (virtual box) that the write is completed, when in reality all that has happened is that the guest OS has completed a write to the virtual filesystem. When you reset the system the write is still going from the hypervisor to the host filesystem, and that is mounted async. Here is what I mean: FreeBSD syncmount on virtual filesystem controlled by hypervisor, in memory memory buffers of hypervisor asyncmounted on host OS, hardware cache mounted on physical disk The FreeBSD guest disk IO is virtual. > Then why it also prematurely declared > completion of the writing and couldn't boot? > > (At the same time, I did confirm that on CentOS the default mount > option includes "async".) There are in this scenario at least 5 layers of disk caching going on: FreeBSD caching to it's virtual filesystem. The virtual filesystem the hypervisor provides is probably also cached in the ram that the host OS gives to the hypervisor in a hypervisor i/o cache. Then the virtual filesystem of the hypervisor is mounted on the disk, so the host OS is running a cache then all that is on the hardware cache of the raid controller And finally, each individual disk of the array has it's own internal cache. The better hardware raid cards are battery-backed up for this reason. All of this is why it's not easy to get the REAL disk throughput of a system because there is so much caching. The tools written to do this have to do fancy stuff like generate data in many multiple files and read and write them back and forth in order to fill up all of the caches so that the systems and disks are unable to cache anything and have to do the actual writes, and the tools have to create and delete many of these files so the systems don't try to get smart and just manipulate files in a memory disk cache somewhere. Ted > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To > unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 07:30:48 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BEFB106566C for ; Wed, 4 May 2011 07:30:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5281F8FC13 for ; Wed, 4 May 2011 07:30:46 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA16297; Wed, 04 May 2011 10:30:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QHWXk-0006RK-HI; Wed, 04 May 2011 10:30:44 +0300 Message-ID: <4DC100A3.1030800@FreeBSD.org> Date: Wed, 04 May 2011 10:30:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Juergen Lock References: <20110503215642.GA26299@triton8.kn-bremen.de> In-Reply-To: <20110503215642.GA26299@triton8.kn-bremen.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:30:48 -0000 on 04/05/2011 00:56 Juergen Lock said the following: > I now tested skype 2.1.0.81 on 8.2 with the above patch and > avg@'s sys/dev/sound/pcm/dsp.c one-line patch [1], and found This is in head now. > sound doesn't work when running skype from nfs without locking > (wtf!), after extracting the skype tarball [2] locally it started > working. Very weird. Have you been able to debug it further (e.g. see with ktrace which calls are failing)? -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 08:06:05 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC9C106566B; Wed, 4 May 2011 08:06:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id EAB4A8FC24; Wed, 4 May 2011 08:06:04 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=oR3+9dOmPeF3nZCt5Gxyvf/bIpfj8bfjGZkkfp/xES8= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=HWTBDsLp_qAA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=ockGNOYkwX6ANAnGUMQA:9 a=8BaGid8w98_xzxsQNccA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 122422957; Wed, 04 May 2011 10:06:02 +0200 From: Hans Petter Selasky To: freebsd-multimedia@freebsd.org Date: Wed, 4 May 2011 10:04:55 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <20110503215642.GA26299@triton8.kn-bremen.de> <4DC100A3.1030800@FreeBSD.org> In-Reply-To: <4DC100A3.1030800@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105041004.55442.hselasky@c2i.net> Cc: freebsd-emulation@freebsd.org, Juergen Lock , Andriy Gapon Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 08:06:06 -0000 On Wednesday 04 May 2011 09:30:43 Andriy Gapon wrote: > on 04/05/2011 00:56 Juergen Lock said the following: > > I now tested skype 2.1.0.81 on 8.2 with the above patch and > > > > avg@'s sys/dev/sound/pcm/dsp.c one-line patch [1], and found > > This is in head now. Don't forget to MFC to 8-stable :-) --HPS From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 09:13:10 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 453C1106566C; Wed, 4 May 2011 09:13:10 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id D64678FC08; Wed, 4 May 2011 09:13:09 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155BB6.dip.t-dialin.net [91.21.91.182]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 4A301844010; Wed, 4 May 2011 11:12:56 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 4414D11D3; Wed, 4 May 2011 11:12:53 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p449Cq8U094928; Wed, 4 May 2011 11:12:52 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 04 May 2011 11:12:52 +0200 Message-ID: <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> Date: Wed, 04 May 2011 11:12:52 +0200 From: Alexander Leidinger To: Juergen Lock References: <20110503215642.GA26299@triton8.kn-bremen.de> In-Reply-To: <20110503215642.GA26299@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 4A301844010.A8393 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.077, required 6, autolearn=disabled, TW_DV 0.08) X-EBL-MailScanner-From: netchild@freebsd.org X-EBL-MailScanner-Watermark: 1305105177.14591@sa1nLzYPz6+7wwoqbLKpRg X-EBL-Spam-Status: No Cc: kwm@FreeBSD.org, hselasky@FreeBSD.org, avg@FreeBSD.org, freebsd-multimedia@FreeBSD.org, ae@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:13:10 -0000 Quoting Juergen Lock (from Tue, 3 May 2011 23:56:42 +0200): > And I also don't want to keep back ae@'s version which builds > as a seperate kld the way I did it for the Linuxolator dvb handler > that is now in ports as multimedia/linux_dvbwrapper-kmod: > > http://people.freebsd.org/~ae/linux_v4l2_kld.tgz > > Maybe we should turn this into a port too for easy user installation > until the patches get committed and for people on (current) releases? I committed the patch to -current. MFC after a month. I didn't bump the FreeBSD revision, so if you want to provide a v4l2 kld, there is no way to know if the kernel has support already or not (but as this is -current, I would say people should update and the port should work only for <9). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Jones' Second Law: The man who smiles when things go wrong has thought of someone to blame it on. From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 09:36:11 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76C1A106566B; Wed, 4 May 2011 09:36:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [77.88.46.7]) by mx1.freebsd.org (Postfix) with ESMTP id 197CC8FC13; Wed, 4 May 2011 09:36:10 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward2.mail.yandex.net (Yandex) with ESMTP id EF0DC12A141F; Wed, 4 May 2011 13:25:11 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1304501112; bh=grrVivhdlVsMo9vbVg2FHAQmaGhik3sdr0l8YSx8LKU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=IKS4Yyjz3hJ6+ktbh7/ZNW0WwUpa+OWIVGc+U2mrgxhW8a/OCG3JDKXs/6d46mrSv begVuD8OWsRidRVJh0CiMOfxMC9BMGSafklER9uT8wOUaJCWpqN3mCKsHpfTFcwfcj s/l1n0X4KxsuOizN49lLpV9ohlaP/XKcorFDLxDA= Received: from [127.0.0.1] (mail.kirov.so-cdu.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 55D7B10000C9; Wed, 4 May 2011 13:25:11 +0400 (MSD) Message-ID: <4DC11B6D.7000205@yandex.ru> Date: Wed, 04 May 2011 13:25:01 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Alexander Leidinger References: <20110503215642.GA26299@triton8.kn-bremen.de> <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> In-Reply-To: <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81DD9FCA22025B50A6744801" X-Yandex-Spam: 1 Cc: kwm@FreeBSD.org, hselasky@FreeBSD.org, Juergen Lock , avg@FreeBSD.org, freebsd-multimedia@FreeBSD.org, ae@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:36:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81DD9FCA22025B50A6744801 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 04.05.2011 13:12, Alexander Leidinger wrote: > want to provide a v4l2 kld, there is no way to know if the kernel has s= upport already or not=20 AFAIK, we have FEATURE() macro for that purpose. --=20 WBR, Andrey V. Elsukov --------------enig81DD9FCA22025B50A6744801 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJNwRtyAAoJEAHF6gQQyKF6TTUH/31tDSkPH6CkknaauzDVYcdO ThmIVaNDe5RJlNKXc9x0c5QUKVBNN2FS1S5y+LXL1AiIAt9H0txCtviPv8PVsIqn KNVLnv0Av/E2JIEnS/nUkqVIq3fT7TepfC6g734OKUQghTr3tDg0iX5bJWMiaNn8 pYwPn78TE05de7ef2p4/QjokbcGAEeDJAOqBx4zTbiXRD/uOVPhLMB2/wveGlvMc 3CUPR06e9NbK0rie2OX+UluTMPYl91cdb9mjNu6k3Ku99MDj7Q30HMwGh2t7co4a mNQwevw9jvy9IzihDa1wKUKofSrm2mXU3MMEbU8/5zxrqj1RfAk9DyY/YbBdCbs= =k+VT -----END PGP SIGNATURE----- --------------enig81DD9FCA22025B50A6744801-- From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 09:53:28 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409931065675; Wed, 4 May 2011 09:53:28 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E22F18FC14; Wed, 4 May 2011 09:53:27 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155BB6.dip.t-dialin.net [91.21.91.182]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 617F684401A; Wed, 4 May 2011 11:53:15 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 92BB311D5; Wed, 4 May 2011 11:53:12 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p449rCKp004604; Wed, 4 May 2011 11:53:12 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 04 May 2011 11:53:12 +0200 Message-ID: <20110504115312.223533eznfjofcow@webmail.leidinger.net> Date: Wed, 04 May 2011 11:53:12 +0200 From: Alexander Leidinger To: "Andrey V. Elsukov" References: <20110503215642.GA26299@triton8.kn-bremen.de> <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> <4DC11B6D.7000205@yandex.ru> In-Reply-To: <4DC11B6D.7000205@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 617F684401A.AC323 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.001, required 6, autolearn=disabled, FSL_RU_URL 0.00) X-EBL-MailScanner-From: netchild@freebsd.org X-EBL-MailScanner-Watermark: 1305107595.71042@Vr9b4qNvmlntciBfIleKhQ X-EBL-Spam-Status: No Cc: kwm@FreeBSD.org, hselasky@FreeBSD.org, Juergen Lock , avg@FreeBSD.org, freebsd-multimedia@FreeBSD.org, ae@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 09:53:28 -0000 Quoting "Andrey V. Elsukov" (from Wed, 04 May 2011 13:25:01 +0400): > On 04.05.2011 13:12, Alexander Leidinger wrote: >> want to provide a v4l2 kld, there is no way to know if the kernel >> has support already or not > > AFAIK, we have FEATURE() macro for that purpose. Done: linuxulator_v4l linuxulator_v4l2 Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 They spell it "da Vinci" and pronounce it "da Vinchy". Foreigners always spell better than they pronounce. -- Mark Twain From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 11:36:45 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71AD8106566C for ; Wed, 4 May 2011 11:36:45 +0000 (UTC) (envelope-from freebsd-emulation@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E71768FC0A for ; Wed, 4 May 2011 11:36:44 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QHaNn-0007gm-6T for freebsd-emulation@freebsd.org; Wed, 04 May 2011 13:36:43 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 May 2011 13:36:43 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 May 2011 13:36:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-emulation@freebsd.org From: Ivan Voras Date: Wed, 04 May 2011 13:36:31 +0200 Lines: 66 Message-ID: References: <32556218.1304447122068.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <32556218.1304447122068.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> X-Enigmail-Version: 1.1.2 Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 11:36:45 -0000 On 03/05/2011 20:25, John wrote: > What I do is to cat the 330MB binary file (XP service pack from Microsoft) 20 times into a single 6.6GB file, "date" before and afterwards, and after the second date finishes, immediately Force power shut down. There are two observations: > > 1. the time to complete copying into this 6.6GB file were 72s, 44s, 79s in three runs, presumably because there is another production VM on the same host. The average is 65s, so it's about 100MB/s. > 2. After immediately power down, I do found the resulting file was less than 6.6GB. So indeed the VM claimed the completion of the copying before it actually did. > > I then did the same thing on the virtualbox, since I don't want the above premature I/O, I made sure the "Use Host I/O cache" is unchecked for the VM storage. > > 1. the time to complete copying into this 6.6GB file was 119s and 92s, the average is 105s, so the speed is 62MB/s. > 2. after immediately "Reset" the machine, I couldn't boot. Both times it asked me to do fsck for that partition (GPT 2.2T). But after finally powering up, I found the file was also less than 6.6GB both times as well. > > So looks like virtualbox also suffers caching problem? Or did I do anything wrong? Aaargh. Please don't invent benchmarks. The ones which are already around have enough troubles by themselves. Instead, if you really want to do a proper comparison of the systems, do this (in the order I've written): 1) add these lines to /etc/sysctl.conf: vfs.hirunningspace=8388608 vfs.lorunningspace=6291456 vfs.read_max=128 2) configure the FreeBSD system to use AHCI http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html 3) use benchmarks/bonnie++ from ports for benchmarking. Note that you need to run *the same version of the benchmark* on all systems (i.e. also on Linux) to be able do do comparison. Any do-it-yourself benchmarks you do are very likely meaningless and you cannot conclude anything from them. Even with this, there could be *huge* differences in the results simply as a consequence of rotational positions of virtual drives on the physical one. See this results (note the transfer rate results). lara:~# diskinfo -vt /dev/ada0 /dev/ada0 512 # sectorsize 500107862016 # mediasize in bytes (466G) 976773168 # mediasize in sectors 0 # stripesize 0 # stripeoffset 969021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. 6QG3Z026 # Disk ident. Seek times: Full stroke: 250 iter in 5.671675 sec = 22.687 msec Half stroke: 250 iter in 4.294470 sec = 17.178 msec Quarter stroke: 500 iter in 6.793844 sec = 13.588 msec Short forward: 400 iter in 2.637252 sec = 6.593 msec Short backward: 400 iter in 2.320116 sec = 5.800 msec Seq outer: 2048 iter in 0.217796 sec = 0.106 msec Seq inner: 2048 iter in 0.218317 sec = 0.107 msec Transfer rates: outside: 102400 kbytes in 1.221390 sec = 83839 kbytes/sec middle: 102400 kbytes in 1.445180 sec = 70856 kbytes/sec inside: 102400 kbytes in 2.451970 sec = 41762 kbytes/sec Benchmarking file systems and drive IO is complicated :) From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 18:28:49 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA98106566B; Wed, 4 May 2011 18:28:49 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 586228FC20; Wed, 4 May 2011 18:28:48 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 02C311E00703; Wed, 4 May 2011 20:28:47 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p44IQ0NI059002; Wed, 4 May 2011 20:26:00 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p44IQ0pd059001; Wed, 4 May 2011 20:26:00 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Wed, 4 May 2011 20:26:00 +0200 To: Andriy Gapon Message-ID: <20110504182600.GA58980@triton8.kn-bremen.de> References: <20110503215642.GA26299@triton8.kn-bremen.de> <4DC100A3.1030800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC100A3.1030800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-multimedia@FreeBSD.org, freebsd-emulation@FreeBSD.org, Juergen Lock Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 18:28:49 -0000 On Wed, May 04, 2011 at 10:30:43AM +0300, Andriy Gapon wrote: > on 04/05/2011 00:56 Juergen Lock said the following: > > I now tested skype 2.1.0.81 on 8.2 with the above patch and > > avg@'s sys/dev/sound/pcm/dsp.c one-line patch [1], and found > > This is in head now. > > > sound doesn't work when running skype from nfs without locking > > (wtf!), after extracting the skype tarball [2] locally it started > > working. > > Very weird. Have you been able to debug it further (e.g. see with ktrace which > calls are failing)? I did some ktrace'ing before I knew it was related to nfs, maybe I'll have to take a closer look again now that I know... Cheers, Juergen From owner-freebsd-emulation@FreeBSD.ORG Wed May 4 18:28:49 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A79F51065679; Wed, 4 May 2011 18:28:49 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 586B08FC27; Wed, 4 May 2011 18:28:48 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 0C3571E000D7; Wed, 4 May 2011 20:28:48 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p44IRexo059020; Wed, 4 May 2011 20:27:40 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p44IRenC059019; Wed, 4 May 2011 20:27:40 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Wed, 4 May 2011 20:27:40 +0200 To: Alexander Leidinger Message-ID: <20110504182740.GB58980@triton8.kn-bremen.de> References: <20110503215642.GA26299@triton8.kn-bremen.de> <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> <4DC11B6D.7000205@yandex.ru> <20110504115312.223533eznfjofcow@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110504115312.223533eznfjofcow@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kwm@FreeBSD.org, hselasky@FreeBSD.org, Juergen Lock , avg@FreeBSD.org, freebsd-multimedia@FreeBSD.org, ae@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 18:28:49 -0000 On Wed, May 04, 2011 at 11:53:12AM +0200, Alexander Leidinger wrote: > > Quoting "Andrey V. Elsukov" (from Wed, 04 May 2011 > 13:25:01 +0400): > > > On 04.05.2011 13:12, Alexander Leidinger wrote: > >> want to provide a v4l2 kld, there is no way to know if the kernel > >> has support already or not > > > > AFAIK, we have FEATURE() macro for that purpose. > > Done: > linuxulator_v4l > linuxulator_v4l2 Thanx you, also for committing! :) I'll see if I can make a port later. Juergen From owner-freebsd-emulation@FreeBSD.ORG Thu May 5 05:33:50 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A9106566B for ; Thu, 5 May 2011 05:33:50 +0000 (UTC) (envelope-from aqqa11@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id E61088FC0C for ; Thu, 5 May 2011 05:33:49 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=f7D9oFzzelehog5RJXwGrPVThKuVpKd11Ckzsj41zmQibmVLT+4AZE0SHFwhPk1W; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QHrC9-0000c6-H4 for freebsd-emulation@freebsd.org; Thu, 05 May 2011 01:33:49 -0400 Received: from 128.59.109.64 by webmail.earthlink.net with HTTP; Thu, 5 May 2011 01:33:48 -0400 Message-ID: <17339409.1304573629442.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Thu, 5 May 2011 01:33:49 -0400 (GMT-04:00) From: John To: freebsd-emulation@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 2552ff5019365d7e94f5150ab1c16ac02930b881f11d255e9501c111e1d4a04bb1c3eda6a02b658e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 05:33:50 -0000 -----Original Message----- >From: Ivan Voras >Sent: May 4, 2011 7:36 AM >To: freebsd-emulation@freebsd.org >Subject: Re: virtualbox I/O 3 times slower than KVM? > >On 03/05/2011 20:25, John wrote: > >> What I do is to cat the 330MB binary file (XP service pack from Microsoft) 20 times into a single 6.6GB file, "date" before and afterwards, and after the second date finishes, immediately Force power shut down. There are two observations: >> >> 1. the time to complete copying into this 6.6GB file were 72s, 44s, 79s in three runs, presumably because there is another production VM on the same host. The average is 65s, so it's about 100MB/s. >> 2. After immediately power down, I do found the resulting file was less than 6.6GB. So indeed the VM claimed the completion of the copying before it actually did. >> >> I then did the same thing on the virtualbox, since I don't want the above premature I/O, I made sure the "Use Host I/O cache" is unchecked for the VM storage. >> >> 1. the time to complete copying into this 6.6GB file was 119s and 92s, the average is 105s, so the speed is 62MB/s. >> 2. after immediately "Reset" the machine, I couldn't boot. Both times it asked me to do fsck for that partition (GPT 2.2T). But after finally powering up, I found the file was also less than 6.6GB both times as well. >> >> So looks like virtualbox also suffers caching problem? Or did I do anything wrong? > >Aaargh. Please don't invent benchmarks. The ones which are already >around have enough troubles by themselves. > >Instead, if you really want to do a proper comparison of the systems, do >this (in the order I've written): > >1) add these lines to /etc/sysctl.conf: > >vfs.hirunningspace=8388608 >vfs.lorunningspace=6291456 >vfs.read_max=128 > >2) configure the FreeBSD system to use AHCI > >http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html > >3) use benchmarks/bonnie++ from ports for benchmarking. Note that you >need to run *the same version of the benchmark* on all systems (i.e. >also on Linux) to be able do do comparison. > >Any do-it-yourself benchmarks you do are very likely meaningless and you >cannot conclude anything from them. Even with this, there could be >*huge* differences in the results simply as a consequence of rotational >positions of virtual drives on the physical one. See this results (note >the transfer rate results). > >lara:~# diskinfo -vt /dev/ada0 >/dev/ada0 > 512 # sectorsize > 500107862016 # mediasize in bytes (466G) > 976773168 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 969021 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > 6QG3Z026 # Disk ident. > >Seek times: > Full stroke: 250 iter in 5.671675 sec = 22.687 msec > Half stroke: 250 iter in 4.294470 sec = 17.178 msec > Quarter stroke: 500 iter in 6.793844 sec = 13.588 msec > Short forward: 400 iter in 2.637252 sec = 6.593 msec > Short backward: 400 iter in 2.320116 sec = 5.800 msec > Seq outer: 2048 iter in 0.217796 sec = 0.106 msec > Seq inner: 2048 iter in 0.218317 sec = 0.107 msec >Transfer rates: > outside: 102400 kbytes in 1.221390 sec = 83839 kbytes/sec > middle: 102400 kbytes in 1.445180 sec = 70856 kbytes/sec > inside: 102400 kbytes in 2.451970 sec = 41762 kbytes/sec > >Benchmarking file systems and drive IO is complicated :) > Well this quickly becomes a debate on what is the most meaningful (or meaningless) I/O benchmark, and clearly people even may not agree on existing I/O benchmarking tools, so I'm not sure how meaningful more test down the road will be. Some later discussions were quite informative, although let's not forget the issues related to virtualbox or/and its implementation of FreeBSD reflected from these tests. It's suffice to say, in the default configuration of FreeBSD (sync mount), at least in one situation (copying a few GB files) the guest FreeBSD of virtualbox has much slower I/O than the host FreeBSD (and the FreeBSD guest on FreeBSD virtualbox is clearly slower than CentOS guest on KVM CentOS, even though the FreeBSD host is slightly faster than CentOS host), AND the guest FreeBSD is fooled into prematurely declaring completion of writing and renders itself unable to boot after reset. Which, I believe, defeated the proud sync mount default of FreeBSD. Whether this can be a typical usage pattern, or whether there are other situation similar (or not similar) to this is another issue. Clearly this is related to virtualbox and its implementation on FreeBSD. I just wish it can improve over time, since virtualbox is the best virtualization solution on *BSD. From owner-freebsd-emulation@FreeBSD.ORG Thu May 5 05:55:37 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C49106566B for ; Thu, 5 May 2011 05:55:37 +0000 (UTC) (envelope-from tedm@mittelstaedt.us) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id F16A78FC19 for ; Thu, 5 May 2011 05:55:36 +0000 (UTC) Received: from [192.168.1.64] (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.14.4/8.14.4) with ESMTP id p455tT6x031988; Wed, 4 May 2011 22:55:29 -0700 (PDT) (envelope-from tedm@mittelstaedt.us) Message-ID: <4DC23BCE.8030007@mittelstaedt.us> Date: Wed, 04 May 2011 22:55:26 -0700 From: Ted Mittelstaedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: John References: <17339409.1304573629442.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> In-Reply-To: <17339409.1304573629442.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.freebsd-corp-net-guide.com Cc: freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times slower than KVM? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 05:55:37 -0000 On 5/4/2011 10:33 PM, John wrote: > > > > -----Original Message----- >> From: Ivan Voras Sent: May 4, 2011 7:36 AM To: >> freebsd-emulation@freebsd.org Subject: Re: virtualbox I/O 3 times >> slower than KVM? >> >> On 03/05/2011 20:25, John wrote: >> >>> What I do is to cat the 330MB binary file (XP service pack from >>> Microsoft) 20 times into a single 6.6GB file, "date" before and >>> afterwards, and after the second date finishes, immediately Force >>> power shut down. There are two observations: >>> >>> 1. the time to complete copying into this 6.6GB file were 72s, >>> 44s, 79s in three runs, presumably because there is another >>> production VM on the same host. The average is 65s, so it's >>> about 100MB/s. 2. After immediately power down, I do found the >>> resulting file was less than 6.6GB. So indeed the VM claimed the >>> completion of the copying before it actually did. >>> >>> I then did the same thing on the virtualbox, since I don't want >>> the above premature I/O, I made sure the "Use Host I/O cache" is >>> unchecked for the VM storage. >>> >>> 1. the time to complete copying into this 6.6GB file was 119s and >>> 92s, the average is 105s, so the speed is 62MB/s. 2. after >>> immediately "Reset" the machine, I couldn't boot. Both times it >>> asked me to do fsck for that partition (GPT 2.2T). But after >>> finally powering up, I found the file was also less than 6.6GB >>> both times as well. >>> >>> So looks like virtualbox also suffers caching problem? Or did I >>> do anything wrong? >> >> Aaargh. Please don't invent benchmarks. The ones which are already >> around have enough troubles by themselves. >> >> Instead, if you really want to do a proper comparison of the >> systems, do this (in the order I've written): >> >> 1) add these lines to /etc/sysctl.conf: >> >> vfs.hirunningspace=8388608 vfs.lorunningspace=6291456 >> vfs.read_max=128 >> >> 2) configure the FreeBSD system to use AHCI >> >> http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html >> >> 3) use benchmarks/bonnie++ from ports for benchmarking. Note that >> you need to run *the same version of the benchmark* on all systems >> (i.e. also on Linux) to be able do do comparison. >> >> Any do-it-yourself benchmarks you do are very likely meaningless >> and you cannot conclude anything from them. Even with this, there >> could be *huge* differences in the results simply as a consequence >> of rotational positions of virtual drives on the physical one. See >> this results (note the transfer rate results). >> >> lara:~# diskinfo -vt /dev/ada0 /dev/ada0 512 # sectorsize >> 500107862016 # mediasize in bytes (466G) 976773168 # mediasize >> in sectors 0 # stripesize 0 # stripeoffset >> 969021 # Cylinders according to firmware. 16 # >> Heads according to firmware. 63 # Sectors according to >> firmware. 6QG3Z026 # Disk ident. >> >> Seek times: Full stroke: 250 iter in 5.671675 sec = 22.687 >> msec Half stroke: 250 iter in 4.294470 sec = 17.178 msec >> Quarter stroke: 500 iter in 6.793844 sec = 13.588 msec Short >> forward: 400 iter in 2.637252 sec = 6.593 msec Short >> backward: 400 iter in 2.320116 sec = 5.800 msec Seq outer: >> 2048 iter in 0.217796 sec = 0.106 msec Seq inner: 2048 iter >> in 0.218317 sec = 0.107 msec Transfer rates: outside: >> 102400 kbytes in 1.221390 sec = 83839 kbytes/sec middle: >> 102400 kbytes in 1.445180 sec = 70856 kbytes/sec inside: >> 102400 kbytes in 2.451970 sec = 41762 kbytes/sec >> >> Benchmarking file systems and drive IO is complicated :) >> > > Well this quickly becomes a debate on what is the most meaningful (or > meaningless) I/O benchmark, and clearly people even may not agree on > existing I/O benchmarking tools, so I'm not sure how meaningful more > test down the road will be. > > Some later discussions were quite informative, although let's not > forget the issues related to virtualbox or/and its implementation of > FreeBSD reflected from these tests. > > It's suffice to say, in the default configuration of FreeBSD (sync > mount), at least in one situation (copying a few GB files) the guest > FreeBSD of virtualbox has much slower I/O than the host FreeBSD (and > the FreeBSD guest on FreeBSD virtualbox is clearly slower than CentOS > guest on KVM CentOS, even though the FreeBSD host is slightly faster > than CentOS host), AND the guest FreeBSD is fooled into prematurely > declaring completion of writing and renders itself unable to boot > after reset. Which, I believe, defeated the proud sync mount default > of FreeBSD. > > Whether this can be a typical usage pattern, or whether there are > other situation similar (or not similar) to this is another issue. > Clearly this is related to virtualbox and its implementation on > FreeBSD. I just wish it can improve over time, since virtualbox is > the best virtualization solution on *BSD. I have run a FreeBSD guest under FreeBSD host using virtualbox for the last year, it runs an accounting package. It is a bit slower than if the OS was bare metal (the host is a dual Xeon 2.0Ghz system so there are 4 cores there - although it is only a 32 bit system) but it has never crashed or caused the host to crash. I';m pretty satisfied that there's not much to be gained in "improving" virtualbox and if I wanted a faster guest I'd buy a faster machine. Ted > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To > unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Thu May 5 21:29:14 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C4B106564A; Thu, 5 May 2011 21:29:13 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 2890D8FC12; Thu, 5 May 2011 21:29:13 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 62BD51E0025C; Thu, 5 May 2011 23:29:12 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p45LSKBe036196; Thu, 5 May 2011 23:28:20 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p45LSJpQ036195; Thu, 5 May 2011 23:28:19 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 5 May 2011 23:28:19 +0200 To: Andriy Gapon Message-ID: <20110505212819.GA36171@triton8.kn-bremen.de> References: <4DB7BC6A.7060207@FreeBSD.org> <20110427163047.GA47520@triton8.kn-bremen.de> <7d7a2fab-7c4e-44ce-bdf2-93811c40a4fe@email.android.com> <20110428193351.GA8814@triton8.kn-bremen.de> <68864477@h30.sp.ipt.ru> <20110428220114.00004b22@unknown> <20110428201939.GA16556@triton8.kn-bremen.de> <4DBA4F77.1000409@FreeBSD.org> <20110429212306.GA43822@triton8.kn-bremen.de> <4DBFF915.3090103@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DBFF915.3090103@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: emulation@FreeBSD.org, HASHI Hiroaki , Juergen Lock , multimedia@FreeBSD.org Subject: Re: audio/linux-f10-alsa-plugins-oss X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 21:29:14 -0000 On Tue, May 03, 2011 at 03:46:13PM +0300, Andriy Gapon wrote: > on 30/04/2011 00:23 Juergen Lock said the following: > > I think now that the port is committed it's the maintainer's call, > > so I Cc'd him. :) > > Cunning :-) Committed now, thanx! (I got portmgr approval, i.e. miwi's...) Juergen From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 08:05:02 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49AA106566C; Fri, 6 May 2011 08:05:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C75238FC0A; Fri, 6 May 2011 08:05:01 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA20834; Fri, 06 May 2011 11:05:00 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QIG1z-000CzU-W9; Fri, 06 May 2011 11:05:00 +0300 Message-ID: <4DC3ABAB.6080707@FreeBSD.org> Date: Fri, 06 May 2011 11:04:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ion-Mihai Tetcu X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: emulation@FreeBSD.org Subject: dns/linux-f10-libasyncns in bsd.linux-apps.mk X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:05:02 -0000 Hi! It seems that currently it is not easy/possible to specify a dependency on dns/linux-f10-libasyncns in some other port. Looks like something like the following is needed (typically done) for that: --- /usr/ports/Mk/bsd.linux-apps.mk 2011-04-28 23:00:24.000000000 +0300 +++ /usr/ports/Mk/bsd.linux-apps.mk 2011-05-06 11:01:40.119728112 +0300 @@ -68,7 +68,7 @@ # 2.6.16 components _LINUX_26_APPS= alsa-plugins-oss blt cyrus-sasl2 dbusglib dbuslibs \ - libidn libssh2 libv4l nspr nss openal-soft \ + libasyncns libidn libssh2 libv4l nspr nss openal-soft \ openldap pulseaudio-libs sqlite3 tcl84 tk84 _LINUX_APPS_ALL+= ${_LINUX_26_APPS} @@ -224,6 +224,11 @@ jpeg_DETECT= ${jpeg${LINUX_DIST_SUFFIX:S/-/_/}_FILE} jpeg_PORT= ${PORTSDIR}/graphics/linux${LINUX_DIST_SUFFIX}-jpeg +libasyncns_FILE= ${LINUXBASE}/usr/lib/libasyncns.so.0.3.1 +libasyncns_f10_FILE= ${LINUXBASE}/usr/lib/libasyncns.so.0.3.1 +libasyncns_DETECT= ${libasyncns${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +libasyncns_PORT= ${PORTSDIR}/dns/linux${LINUX_DIST_SUFFIX}-libasyncns + libaudiofile_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 libaudiofile_f10_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 libaudiofile_DETECT= ${libaudiofile${LINUX_DIST_SUFFIX:S/-/_/}_FILE} -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 08:21:02 2011 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C94D1065674; Fri, 6 May 2011 08:21:02 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E941A8FC0A; Fri, 6 May 2011 08:21:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p468L16p009456; Fri, 6 May 2011 08:21:01 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p468L1rx009425; Fri, 6 May 2011 08:21:01 GMT (envelope-from jh) Date: Fri, 6 May 2011 08:21:01 GMT Message-Id: <201105060821.p468L1rx009425@freefall.freebsd.org> To: misho@aitbg.com, jh@FreeBSD.org, freebsd-emulation@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/144763: [linux] [panic] Kernel panic when start linux binaries X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:21:02 -0000 Synopsis: [linux] [panic] Kernel panic when start linux binaries State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Fri May 6 08:21:00 UTC 2011 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=144763 From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 08:53:27 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01A56106564A; Fri, 6 May 2011 08:53:27 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id B36E28FC12; Fri, 6 May 2011 08:53:26 +0000 (UTC) Received: from User-PC (unknown [81.181.146.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id 4557B22C5562; Fri, 6 May 2011 11:53:25 +0300 (EEST) Date: Fri, 6 May 2011 11:53:20 +0300 From: Ion-Mihai Tetcu To: Andriy Gapon Message-Id: <20110506115320.17cecd7b.itetcu@FreeBSD.org> In-Reply-To: <4DC3ABAB.6080707@FreeBSD.org> References: <4DC3ABAB.6080707@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: emulation@FreeBSD.org Subject: Re: dns/linux-f10-libasyncns in bsd.linux-apps.mk X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:53:27 -0000 On Fri, 06 May 2011 11:04:59 +0300 Andriy Gapon wrote: > > Hi! > > It seems that currently it is not easy/possible to specify a dependency on > dns/linux-f10-libasyncns in some other port. Looks like something like the > following is needed (typically done) for that: Looks good. It's up to bsd.linux-apps.mk maintainers. -- Ion-Mihai Tetcu From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 11:04:00 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C728106566B; Fri, 6 May 2011 11:04:00 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 536198FC1C; Fri, 6 May 2011 11:04:00 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtps (TLSv1:AES128-SHA:128) (Exim 4.54 (FreeBSD)) id 1QIIpC-000NJ5-Dl; Fri, 06 May 2011 15:03:58 +0400 From: Boris Samorodov To: Andriy Gapon References: <4DC3ABAB.6080707@FreeBSD.org> Date: Fri, 06 May 2011 15:03:58 +0400 In-Reply-To: <4DC3ABAB.6080707@FreeBSD.org> (Andriy Gapon's message of "Fri, 06 May 2011 11:04:59 +0300") Message-ID: <04442097@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emulation@FreeBSD.org, Ion-Mihai Tetcu Subject: Re: dns/linux-f10-libasyncns in bsd.linux-apps.mk X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 11:04:00 -0000 On Fri, 06 May 2011 11:04:59 +0300 Andriy Gapon wrote: > It seems that currently it is not easy/possible to specify a dependency on > dns/linux-f10-libasyncns in some other port. Looks like something like the > following is needed (typically done) for that: > --- /usr/ports/Mk/bsd.linux-apps.mk 2011-04-28 23:00:24.000000000 +0300 > +++ /usr/ports/Mk/bsd.linux-apps.mk 2011-05-06 11:01:40.119728112 +0300 > @@ -68,7 +68,7 @@ > # 2.6.16 components > _LINUX_26_APPS= alsa-plugins-oss blt cyrus-sasl2 dbusglib dbuslibs \ > - libidn libssh2 libv4l nspr nss openal-soft \ > + libasyncns libidn libssh2 libv4l nspr nss openal-soft \ > openldap pulseaudio-libs sqlite3 tcl84 tk84 > _LINUX_APPS_ALL+= ${_LINUX_26_APPS} > @@ -224,6 +224,11 @@ > jpeg_DETECT= ${jpeg${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > jpeg_PORT= ${PORTSDIR}/graphics/linux${LINUX_DIST_SUFFIX}-jpeg > +libasyncns_FILE= ${LINUXBASE}/usr/lib/libasyncns.so.0.3.1 There is no port for fc4 distro, so no need in this line. A typical way is to use a comment line like "# no libasyncns_FILE (there is no libasyncns port for Fedora 4 distribution)" > +libasyncns_f10_FILE= ${LINUXBASE}/usr/lib/libasyncns.so.0.3.1 > +libasyncns_DETECT= ${libasyncns${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > +libasyncns_PORT= ${PORTSDIR}/dns/linux${LINUX_DIST_SUFFIX}-libasyncns > + > libaudiofile_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 > libaudiofile_f10_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 > libaudiofile_DETECT= ${libaudiofile${LINUX_DIST_SUFFIX:S/-/_/}_FILE} Other than that looks fine. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 11:54:08 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB8B106564A; Fri, 6 May 2011 11:54:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 523CC8FC0C; Fri, 6 May 2011 11:54:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23558; Fri, 06 May 2011 14:53:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DC3E156.4000704@FreeBSD.org> Date: Fri, 06 May 2011 14:53:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Boris Samorodov References: <4DC3ABAB.6080707@FreeBSD.org> <04442097@bb.ipt.ru> In-Reply-To: <04442097@bb.ipt.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: emulation@FreeBSD.org, Ion-Mihai Tetcu Subject: Re: dns/linux-f10-libasyncns in bsd.linux-apps.mk X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 11:54:08 -0000 on 06/05/2011 14:03 Boris Samorodov said the following: > On Fri, 06 May 2011 11:04:59 +0300 Andriy Gapon wrote: > There is no port for fc4 distro, so no need in this line. A typical way > is to use a comment line like "# no libasyncns_FILE (there is no > libasyncns port for Fedora 4 distribution)" > >> +libasyncns_f10_FILE= ${LINUXBASE}/usr/lib/libasyncns.so.0.3.1 >> +libasyncns_DETECT= ${libasyncns${LINUX_DIST_SUFFIX:S/-/_/}_FILE} >> +libasyncns_PORT= ${PORTSDIR}/dns/linux${LINUX_DIST_SUFFIX}-libasyncns >> + >> libaudiofile_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 >> libaudiofile_f10_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 >> libaudiofile_DETECT= ${libaudiofile${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > > Other than that looks fine. > Thank you for the review! Can you please commit it with your suggestions applied? I am working on a new skype port and it would need this dependency. Thank you! -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 12:23:13 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 416FC1065670; Fri, 6 May 2011 12:23:13 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id EBC1D8FC13; Fri, 6 May 2011 12:23:12 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtps (TLSv1:AES128-SHA:128) (Exim 4.54 (FreeBSD)) id 1QIK3r-000NOP-Oi; Fri, 06 May 2011 16:23:11 +0400 From: Boris Samorodov To: Andriy Gapon References: <4DC3ABAB.6080707@FreeBSD.org> <04442097@bb.ipt.ru> <4DC3E156.4000704@FreeBSD.org> Date: Fri, 06 May 2011 16:23:11 +0400 In-Reply-To: <4DC3E156.4000704@FreeBSD.org> (Andriy Gapon's message of "Fri, 06 May 2011 14:53:58 +0300") Message-ID: <79487696@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emulation@FreeBSD.org, Ion-Mihai Tetcu Subject: Re: dns/linux-f10-libasyncns in bsd.linux-apps.mk X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 12:23:13 -0000 On Fri, 06 May 2011 14:53:58 +0300 Andriy Gapon wrote: > on 06/05/2011 14:03 Boris Samorodov said the following: > > On Fri, 06 May 2011 11:04:59 +0300 Andriy Gapon wrote: > > There is no port for fc4 distro, so no need in this line. A typical way > > is to use a comment line like "# no libasyncns_FILE (there is no > > libasyncns port for Fedora 4 distribution)" > > > >> +libasyncns_f10_FILE= ${LINUXBASE}/usr/lib/libasyncns.so.0.3.1 > >> +libasyncns_DETECT= ${libasyncns${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > >> +libasyncns_PORT= ${PORTSDIR}/dns/linux${LINUX_DIST_SUFFIX}-libasyncns > >> + > >> libaudiofile_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 > >> libaudiofile_f10_FILE= ${LINUXBASE}/usr/lib/libaudiofile.so.0.0.2 > >> libaudiofile_DETECT= ${libaudiofile${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > > > > Other than that looks fine. > Can you please commit it with your suggestions applied? Done. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 22:16:15 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A774106566B; Fri, 6 May 2011 22:16:15 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 373A88FC17; Fri, 6 May 2011 22:16:14 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id C523C1E00231; Sat, 7 May 2011 00:16:13 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p46LMaq5022982; Fri, 6 May 2011 23:22:36 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p46LMaRR022981; Fri, 6 May 2011 23:22:36 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 6 May 2011 23:22:36 +0200 To: Juergen Lock Message-ID: <20110506212236.GA22733@triton8.kn-bremen.de> References: <20110503215642.GA26299@triton8.kn-bremen.de> <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> <4DC11B6D.7000205@yandex.ru> <20110504115312.223533eznfjofcow@webmail.leidinger.net> <20110504182740.GB58980@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110504182740.GB58980@triton8.kn-bremen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kwm@FreeBSD.org, Alexander Leidinger , hselasky@FreeBSD.org, avg@FreeBSD.org, freebsd-multimedia@FreeBSD.org, ae@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 22:16:15 -0000 On Wed, May 04, 2011 at 08:27:40PM +0200, Juergen Lock wrote: > On Wed, May 04, 2011 at 11:53:12AM +0200, Alexander Leidinger wrote: > > > > Quoting "Andrey V. Elsukov" (from Wed, 04 May 2011 > > 13:25:01 +0400): > > > > > On 04.05.2011 13:12, Alexander Leidinger wrote: > > >> want to provide a v4l2 kld, there is no way to know if the kernel > > >> has support already or not > > > > > > AFAIK, we have FEATURE() macro for that purpose. > > > > Done: > > linuxulator_v4l > > linuxulator_v4l2 > > Thanx you, also for committing! :) > > I'll see if I can make a port later. First version ready, also at: http://people.freebsd.org/~nox/dvb/linux_v4l2wrapper-kmod.shar Pleas test/comment... :) Thanx, Juergen # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # linux_v4l2wrapper-kmod/ # linux_v4l2wrapper-kmod/Makefile # linux_v4l2wrapper-kmod/distinfo # linux_v4l2wrapper-kmod/pkg-descr # linux_v4l2wrapper-kmod/files/ # linux_v4l2wrapper-kmod/files/patch-Makefile # linux_v4l2wrapper-kmod/files/patch-linux_v4l2.c # echo c - linux_v4l2wrapper-kmod/ mkdir -p linux_v4l2wrapper-kmod/ > /dev/null 2>&1 echo x - linux_v4l2wrapper-kmod/Makefile sed 's/^X//' >linux_v4l2wrapper-kmod/Makefile << 'f00048d7c6818b8fd8b16fa54c7100d8' X# New ports collection makefile for: linux_v4l2wrapper-kmod X# Date created: Fri May 6 22:30:00 CEST 2011 X# Whom: nox@FreeBSD.org X# X# $FreeBSD: $ X# X XPORTNAME= linux_v4l2wrapper-kmod XPORTVERSION= 1.0 XCATEGORIES= multimedia kld XMASTER_SITES= http://people.freebsd.org/~ae/ XDISTNAME= linux_v4l2_kld XEXTRACT_SUFX= .tgz X XMAINTAINER= nox@FreeBSD.org XCOMMENT= Linux compatibility layer - V4L2 ioctl handler X XONLY_FOR_ARCHS= i386 amd64 XPATCH_STRIP= -p1 XWRKSRC= ${WRKDIR}/linux_v4l2 X X.include X XPLIST_FILES+= "@cwd /" XPLIST_FILES+= ${KMODDIR:C,^/,,}/linux_v4l2wrapper.ko XPLIST_FILES+= "@exec kldxref ${KMODDIR}" XPLIST_FILES+= "@unexec kldxref ${KMODDIR}" X X# install where x11/nvidia-driver does also: XKMODDIR= /boot/modules X XMAKE_ENV+= KMODDIR="${KMODDIR}" X XSYSDIR?= ${SRC_BASE}/sys XMAKE_ENV+= SYSDIR="${SYSDIR}" X XCFLAGS+= ${DEBUG_FLAGS} X X# try to avoid child process when finding out if already in the kernel X.if ${OSVERSION} > 900036 XINBASE= 1 X.else X.if ${OSVERSION} == 900036 XINBASE!= ($(SYSCTL) -n kern.features.linuxulator_v4l2 2>/dev/null 2>/dev/null || true) X.else XINBASE= 0 X.endif X.endif X X.if ${INBASE} == "1" XIGNORE= is already in kernel X.else X.if !exists(${SYSDIR}/Makefile) XIGNORE= requires kernel source to be installed X.endif X.endif X X.include f00048d7c6818b8fd8b16fa54c7100d8 echo x - linux_v4l2wrapper-kmod/distinfo sed 's/^X//' >linux_v4l2wrapper-kmod/distinfo << '26d01d887cd79f3f861aedca6c373c9f' XSHA256 (linux_v4l2_kld.tgz) = 1d8d4fad58bc829f85541d41d5e29425e1453375d6b25848c20eea677119ee32 XSIZE (linux_v4l2_kld.tgz) = 22170 26d01d887cd79f3f861aedca6c373c9f echo x - linux_v4l2wrapper-kmod/pkg-descr sed 's/^X//' >linux_v4l2wrapper-kmod/pkg-descr << '693c30a938bcc6461a28e97353ca5346' XThis kld adds V4L2 ioctl handling to the Linux compatibility layer Xso that Linux apps can talk to V4L2 devices (like webcams) via X/dev/videoX. The patches this kld is based on have been committed Xto FreeBSD 9.0-current now so this port is only needed on eaerlier Xversions. X XNote this port does not contain actual V4L2 drivers, those are Xprovided by e.g. the multimedia/webcamd port. X XWWW: http://people.freebsd.org/~nox/dvb/ 693c30a938bcc6461a28e97353ca5346 echo c - linux_v4l2wrapper-kmod/files/ mkdir -p linux_v4l2wrapper-kmod/files/ > /dev/null 2>&1 echo x - linux_v4l2wrapper-kmod/files/patch-Makefile sed 's/^X//' >linux_v4l2wrapper-kmod/files/patch-Makefile << 'f867d3b6a52dfbd690ce66d177d0b239' X--- a/Makefile X+++ b/Makefile X@@ -1,11 +1,11 @@ X # $FreeBSD$ X X-.if ${MACHINE_CPUARCH} == "amd64" X+.if ${MACHINE_ARCH} == "amd64" X SFX= 32 X CFLAGS+=-DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 X .endif X X-KMOD= linux_v4l2 X+KMOD= linux_v4l2wrapper X SRCS= linux_v4l2.c X X .include f867d3b6a52dfbd690ce66d177d0b239 echo x - linux_v4l2wrapper-kmod/files/patch-linux_v4l2.c sed 's/^X//' >linux_v4l2wrapper-kmod/files/patch-linux_v4l2.c << 'fcbef861bf23ec0e44d09a68f94a3bfb' X--- a/linux_v4l2.c X+++ b/linux_v4l2.c X@@ -47,8 +47,6 @@ __FBSDID("$FreeBSD$"); X #endif X X #include X-#include X-#include X X #include "linux_v4l2_ioctl.h" X #include "linux_videodev2.h" fcbef861bf23ec0e44d09a68f94a3bfb exit From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 22:47:12 2011 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8D9F106564A; Fri, 6 May 2011 22:47:11 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4108FC15; Fri, 6 May 2011 22:47:10 +0000 (UTC) Received: by ewy1 with SMTP id 1so1414270ewy.13 for ; Fri, 06 May 2011 15:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0pjbyiAh/B+V/YLJ4dV7zng1bojdnueQab+jWPMAPnU=; b=siLC8OnnbkZmw1l3KJbQ3K8DBysgYtazSsW1sZ8y+qPdID+fBn36a9GzleprzJKFS9 eaCSTzxDCiVYJMdbsqOcVMe6EZBymWiRspmh9Uaij1HGtT94ThMh2Q/vXWwDXT1SPO04 HY023vkosrvAdK7vgEuF+PrlMvodP3Y8eKJ6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pNeBnJD9P9mAb0P3sokH5mfe8hAHH6JJkNElwbUUkbI/fItmNz+54krDZSovdJZ4AP Uv7bQeVhJiUpiE8h30ZjnEhPi9oTlVHDYSIGU3eZ+aQyq1E0+ONrmZzATzj9Mo+G2iex 2NpzsWOMF5kaT2lvCuvKWvJmIVa9jlDp2lf4Q= MIME-Version: 1.0 Received: by 10.213.3.20 with SMTP id 20mr54986ebl.47.1304722028013; Fri, 06 May 2011 15:47:08 -0700 (PDT) Received: by 10.213.25.139 with HTTP; Fri, 6 May 2011 15:47:07 -0700 (PDT) In-Reply-To: References: <430fcb25aefc374bf256e45e3151de15@bluelife.at> <9c0bedf7a0e9f131712e7c3bab754ecd@bluelife.at> Date: Fri, 6 May 2011 18:47:07 -0400 Message-ID: From: Ryan Stone To: Bernhard Froehlich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: emulation@freebsd.org, ports@freebsd.org Subject: Re: Call for Testers: VirtualBox 4.0.6 (PBIs now available) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 22:47:12 -0000 On Wed, Apr 27, 2011 at 3:28 PM, Ryan Stone wrote: > (Sorry for the noise earlier about the PBIs not working under PC-BSD; > I'm not sure how I missed that had been already reported). > > I tried the new amd64 PBI and I am able to successfully start VMs now. > =A0I had one VM(running some relatively recent version of amd64 HEAD) > boot up fine, but a second one (also running amd64 HEAD, but maybe a > different svn revision) gets a Guru Meditation during startup. =A0I'm > not sure what is causing the crash. =A0In their original configurations > the working VM booted off of an emulated IDE disk while the broken VM > booted of an emulated SATA disk, however I just tried changing the > SATA disk to instead be an IDE disk and it doesn't seems to have > resolved the problem. > > I'm not getting a corefile for the crash(or I'm unable to find it). =A0I > do have kern.sugid_coredump=3D1 and I'm running the PBI. =A0Is this > expected for a Guru Meditation, or should it be putting a core > somewhere? =A0I've put the VBox.log for the most recent crash here: > > http://people.freebsd.org/~rstone/vbox-4.0.6/VBox.log > > This seems to be easy to reproduce so let me know if there's any more > information that I can gather. > > > Also, the working VM was emulating uniprocessor machine. =A0I tried > adding a second CPU and that VM started crashing, too. =A0I tried > changing the broken VM to have only one core but it still crashes. > I'm not sure if it's related to the first crash or not. > To follow up, I tried playing around with the "working" VM configuration. I can only make it fail if I emulate a machine with multiple processors and I leave SMP enabled in the kernel. If I either emulate a uniprocessor machine or disable SMP via tunable, the VM is able to boot without crashing. To summarize, I believe that I am running into two separate issues with VirtualBox 4.0.6: - Booting off of an emulated SATA drive leads to crashes during boot: http://people.freebsd.org/~rstone/vbox-4.0.6/VBox.log (Guru Meditation -4001 (VERR_VMX_INVALID_VMCS_PTR) ) - Booting a VM with multiple virtual processors on a kernel with SMP enabled crashes during boot: http://people.freebsd.org/~rstone/vbox-4.0.6/VBox-SMP.log (Guru Meditation -4002 (VERR_VMX_INVALID_VMXON_PTR)) From owner-freebsd-emulation@FreeBSD.ORG Fri May 6 22:49:26 2011 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB658106564A; Fri, 6 May 2011 22:49:26 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC35D8FC15; Fri, 6 May 2011 22:49:25 +0000 (UTC) Received: by ewy1 with SMTP id 1so1414646ewy.13 for ; Fri, 06 May 2011 15:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HjQ1bXUf4gXMvd7AZjxiHVhuLUijBisNLXXK+pNubu4=; b=ll0MBwXlmV5cR67d51EhbO7VnSCgEA7LlcLv4MAwcvkcnW0dDV6VIqHsRWV0dQDn71 UVqbjMLkqDGTzxGA4vrDvOXflScrsQa5l3dfDv9nEhcJmLtDnqB9UoDtmlTeRniA4gin mJTj90EZoNm+hBi1Itf1rEUv74YRY7iJ4nZUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KbOlJAaS5tE+SdFZy2xxa8hai+4cexPlslYHJ9RIDkMp/qNTANtkQGMiQX3noNFirW EuLmXIUbo9WqDEKu3f2FTMnfOg8mWrLcBLfHijS0cjDD2u2zrSqdPrrJNVonbFloFRlg 3at19BOd12t1bGHGmy2sYp0/r1ff3kimPRi04= MIME-Version: 1.0 Received: by 10.213.108.147 with SMTP id f19mr61051ebp.9.1304722163575; Fri, 06 May 2011 15:49:23 -0700 (PDT) Received: by 10.213.25.139 with HTTP; Fri, 6 May 2011 15:49:23 -0700 (PDT) In-Reply-To: References: <430fcb25aefc374bf256e45e3151de15@bluelife.at> <9c0bedf7a0e9f131712e7c3bab754ecd@bluelife.at> Date: Fri, 6 May 2011 18:49:23 -0400 Message-ID: From: Ryan Stone To: Bernhard Froehlich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: emulation@freebsd.org, ports@freebsd.org Subject: Re: Call for Testers: VirtualBox 4.0.6 (PBIs now available) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 22:49:26 -0000 On Fri, May 6, 2011 at 6:47 PM, Ryan Stone wrote: > On Wed, Apr 27, 2011 at 3:28 PM, Ryan Stone wrote: >> (Sorry for the noise earlier about the PBIs not working under PC-BSD; >> I'm not sure how I missed that had been already reported). >> >> I tried the new amd64 PBI and I am able to successfully start VMs now. >> =A0I had one VM(running some relatively recent version of amd64 HEAD) >> boot up fine, but a second one (also running amd64 HEAD, but maybe a >> different svn revision) gets a Guru Meditation during startup. =A0I'm >> not sure what is causing the crash. =A0In their original configurations >> the working VM booted off of an emulated IDE disk while the broken VM >> booted of an emulated SATA disk, however I just tried changing the >> SATA disk to instead be an IDE disk and it doesn't seems to have >> resolved the problem. >> >> I'm not getting a corefile for the crash(or I'm unable to find it). =A0I >> do have kern.sugid_coredump=3D1 and I'm running the PBI. =A0Is this >> expected for a Guru Meditation, or should it be putting a core >> somewhere? =A0I've put the VBox.log for the most recent crash here: >> >> http://people.freebsd.org/~rstone/vbox-4.0.6/VBox.log >> >> This seems to be easy to reproduce so let me know if there's any more >> information that I can gather. >> >> >> Also, the working VM was emulating uniprocessor machine. =A0I tried >> adding a second CPU and that VM started crashing, too. =A0I tried >> changing the broken VM to have only one core but it still crashes. >> I'm not sure if it's related to the first crash or not. >> > > To follow up, I tried playing around with the "working" VM > configuration. =A0I can only make it fail if I emulate a machine with > multiple processors and I leave SMP enabled in the kernel. =A0If I > either emulate a uniprocessor machine or disable SMP via tunable, the > VM is able to boot without crashing. > > To summarize, I believe that I am running into two separate issues > with VirtualBox 4.0.6: > - Booting off of an emulated SATA drive leads to crashes during boot: > http://people.freebsd.org/~rstone/vbox-4.0.6/VBox.log (Guru Meditation > -4001 (VERR_VMX_INVALID_VMCS_PTR) > ) > - Booting a VM with multiple virtual processors on a kernel with SMP > enabled crashes during boot: > http://people.freebsd.org/~rstone/vbox-4.0.6/VBox-SMP.log (Guru > Meditation -4002 (VERR_VMX_INVALID_VMXON_PTR)) > It occurs to me that I've left out a very important piece of information. I was previously able to boot the SATA, dual-core VM under VirtualBox 4.0.4, so this is a very recent regression. From owner-freebsd-emulation@FreeBSD.ORG Sat May 7 09:48:49 2011 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 945FD1065672 for ; Sat, 7 May 2011 09:48:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BFD438FC17 for ; Sat, 7 May 2011 09:48:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA06032 for ; Sat, 07 May 2011 12:48:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QIe7z-0004Ba-6S for emulation@FreeBSD.org; Sat, 07 May 2011 12:48:47 +0300 Message-ID: <4DC5157E.2020606@FreeBSD.org> Date: Sat, 07 May 2011 12:48:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: emulation@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: pls review: dummy handlers for linux wlan ioctls X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 09:48:49 -0000 The purpose of this code is just to reduce amount of noise produced when some software uses those ioctls (e.g. newer Skype). All ioctls return ENOTSUP. linux emu: add dummy handler for ioctls related to wireless interfaces diff --git a/sys/compat/linux/linux_ioctl.c b/sys/compat/linux/linux_ioctl.c index 63f6888..7d90402 100644 --- a/sys/compat/linux/linux_ioctl.c +++ b/sys/compat/linux/linux_ioctl.c @@ -110,6 +110,7 @@ static linux_ioctl_function_t linux_ioctl_v4l; static linux_ioctl_function_t linux_ioctl_v4l2; static linux_ioctl_function_t linux_ioctl_special; static linux_ioctl_function_t linux_ioctl_fbsd_usb; +static linux_ioctl_function_t linux_ioctl_wlan; static struct linux_ioctl_handler cdrom_handler = { linux_ioctl_cdrom, LINUX_IOCTL_CDROM_MIN, LINUX_IOCTL_CDROM_MAX }; @@ -139,6 +140,8 @@ static struct linux_ioctl_handler video2_handler = { linux_ioctl_v4l2, LINUX_IOCTL_VIDEO2_MIN, LINUX_IOCTL_VIDEO2_MAX }; static struct linux_ioctl_handler fbsd_usb = { linux_ioctl_fbsd_usb, FBSD_LUSB_MIN, FBSD_LUSB_MAX }; +static struct linux_ioctl_handler wlan_handler = +{ linux_ioctl_wlan, LINUX_IOCTL_WLAN_MIN, LINUX_IOCTL_WLAN_MAX }; DATA_SET(linux_ioctl_handler_set, cdrom_handler); DATA_SET(linux_ioctl_handler_set, vfat_handler); @@ -154,6 +157,7 @@ DATA_SET(linux_ioctl_handler_set, sg_handler); DATA_SET(linux_ioctl_handler_set, video_handler); DATA_SET(linux_ioctl_handler_set, video2_handler); DATA_SET(linux_ioctl_handler_set, fbsd_usb); +DATA_SET(linux_ioctl_handler_set, wlan_handler); struct handler_element { @@ -2598,6 +2602,24 @@ linux_ioctl_private(struct thread *td, struct linux_ioctl_args *args) } /* + * Wireless interface ioctl handler + */ +static int +linux_ioctl_wlan(struct thread *td, struct linux_ioctl_args *args) +{ + struct file *fp; + int error, type; + + if ((error = fget(td, args->fd, &fp)) != 0) + return (error); + type = fp->f_type; + fdrop(fp, td); + if (type == DTYPE_SOCKET) + return (ENOTSUP); + return (ENOIOCTL); +} + +/* * DRM ioctl handler (sys/dev/drm) */ static int diff --git a/sys/compat/linux/linux_ioctl.h b/sys/compat/linux/linux_ioctl.h index a7ecbab..24b8d88f 100644 --- a/sys/compat/linux/linux_ioctl.h +++ b/sys/compat/linux/linux_ioctl.h @@ -257,6 +257,13 @@ #define LINUX_IOCTL_PRIVATE_MAX LINUX_SIOCDEVPRIVATE+0xf /* + * Wireless interfaces ioctl calls + */ +#define SIOCGIWNAME 0x8b01 +#define LINUX_IOCTL_WLAN_MIN 0x8b00 +#define LINUX_IOCTL_WLAN_MAX 0x8bff + +/* * sound */ #define LINUX_SOUND_MIXER_WRITE_VOLUME 0x4d00 -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Sat May 7 11:44:29 2011 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A32F1065670; Sat, 7 May 2011 11:44:29 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE268FC13; Sat, 7 May 2011 11:44:28 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id EBCA51E0020E; Sat, 7 May 2011 13:44:27 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p47BgpgF003183; Sat, 7 May 2011 13:42:51 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p47BgpC2003182; Sat, 7 May 2011 13:42:51 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 7 May 2011 13:42:50 +0200 To: Juergen Lock Message-ID: <20110507114250.GA3152@triton8.kn-bremen.de> References: <20110503215642.GA26299@triton8.kn-bremen.de> <20110504111252.11606aa6la3gcsso@webmail.leidinger.net> <4DC11B6D.7000205@yandex.ru> <20110504115312.223533eznfjofcow@webmail.leidinger.net> <20110504182740.GB58980@triton8.kn-bremen.de> <20110506212236.GA22733@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110506212236.GA22733@triton8.kn-bremen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kwm@FreeBSD.org, Alexander Leidinger , hselasky@FreeBSD.org, avg@FreeBSD.org, freebsd-multimedia@FreeBSD.org, ae@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: Re: skype 2.1.0.81; alternate versions of the Linuxolator v4l2 patches X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 11:44:29 -0000 On Fri, May 06, 2011 at 11:22:36PM +0200, Juergen Lock wrote: > On Wed, May 04, 2011 at 08:27:40PM +0200, Juergen Lock wrote: > > On Wed, May 04, 2011 at 11:53:12AM +0200, Alexander Leidinger wrote: > > > > > > Quoting "Andrey V. Elsukov" (from Wed, 04 May 2011 > > > 13:25:01 +0400): > > > > > > > On 04.05.2011 13:12, Alexander Leidinger wrote: > > > >> want to provide a v4l2 kld, there is no way to know if the kernel > > > >> has support already or not > > > > > > > > AFAIK, we have FEATURE() macro for that purpose. > > > > > > Done: > > > linuxulator_v4l > > > linuxulator_v4l2 > > > > Thanx you, also for committing! :) > > > > I'll see if I can make a port later. > > First version ready, also at: > > http://people.freebsd.org/~nox/dvb/linux_v4l2wrapper-kmod.shar > > Pleas test/comment... :) Did some cosmetic changes and mirrored the distfile on MASTER_SITE_LOCAL, new shar at the same place. Testing/review still welcome... :) Juergen From owner-freebsd-emulation@FreeBSD.ORG Sat May 7 14:10:53 2011 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E90A106566B for ; Sat, 7 May 2011 14:10:53 +0000 (UTC) (envelope-from francois.gerodez@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0930E8FC13 for ; Sat, 7 May 2011 14:10:52 +0000 (UTC) Received: by iwn33 with SMTP id 33so4683815iwn.13 for ; Sat, 07 May 2011 07:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=eKCwqR3EI9t7F/lSoYkrL3kVfJXO8O/GTMRL2izEvqg=; b=PpxA7zhkYUs6Q9mjJyPuGa9wo+XS1aqZQL2o/I8tSoZB0QefaVMdoVY4C5OEaXhkOP A8vtCwOeyubl4fG3TbhyYHuvBiwBRTX3PozA4BJmC2CfhKdt/uTwQ8QoN1xrqvV5J3u9 R5I/i40ZtRyhWNhCrYuoz912TU8tMYPJJjm7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fn2No5gEYNxG62SMoftub6JtkLg+DU5+cm0/fiEZDiLOMGIvtaU8ohO24/5M/8yjSR oQK/o3GaSi//m8y3W5x4Ct6rk5cjgwZqXSxnHt24sTt3lSjQWvEyiNXqjkfeX2JoFxar lvywhB369IjfcN4K4W3/ms20wu2z5zRqiwiZ8= MIME-Version: 1.0 Received: by 10.231.74.84 with SMTP id t20mr3147479ibj.38.1304775614641; Sat, 07 May 2011 06:40:14 -0700 (PDT) Received: by 10.231.37.131 with HTTP; Sat, 7 May 2011 06:40:14 -0700 (PDT) Date: Sat, 7 May 2011 15:40:14 +0200 Message-ID: From: Francois Gerodez To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: wincodecs can't find libjpeg.so.11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 14:10:53 -0000 Hi, I've installed wine 1.3.6 on freebsd amd64 (8.1). Everything works just fin= e except for programs that need to display JPEG images : err:ole:OleLoadPicture IPersistStream_Load failed err:wincodecs:JpegDecoder_CreateInstance Failed reading JPEG because unable to find libjpeg.so.11 I've tried putting libjpeg.so.11 into /usr/lib32 /usr/local/lib32 /usr/local/lib32/wine... nothing seems to work... Any ideas? Thanks, Fran=E7ois From owner-freebsd-emulation@FreeBSD.ORG Sat May 7 15:46:47 2011 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55912106567A; Sat, 7 May 2011 15:46:47 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 296E78FC17; Sat, 7 May 2011 15:46:46 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p47FQawo081728; Sat, 7 May 2011 08:26:36 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4DC565ED.1060008@rawbw.com> Date: Sat, 07 May 2011 08:31:57 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101211 Thunderbird/3.0.11 MIME-Version: 1.0 To: Bernhard Froehlich References: <430fcb25aefc374bf256e45e3151de15@bluelife.at> In-Reply-To: <430fcb25aefc374bf256e45e3151de15@bluelife.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: emulation@freebsd.org Subject: Re: Call for Testers: VirtualBox 4.0.6 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 15:46:47 -0000 I had Ubuntu (64bit) VM with the snapshot, created under vbox-4.0.4. Now after upgrading to vbox-4.0.6 I restored this snapshot. But when trying to start the machine it fails with the message: Failed to open session for the virtual machine Ubuntu64. Failed to load unit 'HGCM' (VERR_INVALID_PARAMETER). Details Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: ICOnsole {....} Not sure what to do with this machine now. Yuri