From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 03:56:20 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 825AB106564A; Sun, 22 Jul 2012 03:56:20 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 595F38FC12; Sun, 22 Jul 2012 03:56:20 +0000 (UTC) Received: from [192.168.1.2] (pool-72-89-250-138.nycmny.fios.verizon.net [72.89.250.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 5A6C01B4165; Sun, 22 Jul 2012 03:56:19 +0000 (UTC) Message-ID: <500B795B.7000307@gentoo.org> Date: Sat, 21 Jul 2012 23:54:03 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120628 Thunderbird/10.0.5 MIME-Version: 1.0 To: Wojciech Puchar References: <50085193.6030203@gentoo.org> <5009DB2A.7070408@gentoo.org> <500A13A6.7030503@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFA60BE77987BC02D52E16480" Cc: Adrian Chadd , "hackers@FreeBSD.org" , current@freebsd.org, ivoras@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 03:56:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFA60BE77987BC02D52E16480 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/21/2012 04:15 AM, Wojciech Puchar wrote: >> da0: Fixed Direct Access SCSI-5 device >> da0: 3.300MB/s transfers >> da0: Command Queueing enabled >> da0: 409600MB (838860800 512 byte sectors: 255H 63S/T 52216C) >> >> It does not explain why virtio is slow though, although I still need t= o >> test virtio against the latest code. I will do ivan's raw block test >> against virtio-blk, mainly because there is no point in doing it again= st >> a device whose transfers have been capped to 3.3MB/sec. > are you sure it is really capped? > i am not. just emulated sym device reports low speed. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" You are right. It is not capped at that speed: root@freebsd:/root # dd if=3D/dev/zero of=3D/dev/da1 bs=3D16384 count=3D2= 62144 262144+0 records in 262144+0 records out 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) --------------enigFA60BE77987BC02D52E16480 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQC3leAAoJECDuEZm+6ExkIaoP/AlnAKsNV/TKyZE06jLnptUr vB+ta9hq3V3wnSbQbWKYTdCbqRP5Rsc6Q6t5ixPND/VmtEEFStQDtYN3qWKQauwT fGwOGBNCyAnRtbAhtaLGOaIzTmVzj4LOdEfzDQJxkIg1xdoERBxrO0w+tm5Axun2 FaTMZlrRpalp17whe+gcHv0RZGR73B4uRbKtXKkSt/38mCoOX7ghWMvgkCd3OTC3 tf8xbRtPBKk6GzozdELEPkQBE0NDADmUjFGCUGqz7ogkgFDSp7rR0YJeukmVosIZ x4KLXlEiDls49+3SCLRIRP8XYhZ9IkR1+XJNIvQi+MLltrj98XwjbBuzKDXbjp8t VGiGZEfLfoz88wfqtjA6Af2xcSiAg1W5pXdz1NB1Fg63YrHrRQSMb17wW0RvY4i9 5mroZbqAQmrgMSHN74/+5O8eMOCgo8d+IqxSy3pHrEd+Z+fH9NyVmSU+AByjLU2f nwITMDfd1MqvnNQbRTP80JjSDha5DYT5l56S8XvgmB5q9gJ8j+qsI2qXtmNBQDye W9ngQiyiXU+SSAdyPPajIYt9rCCvw8itrE23wuq23TEecbO2EvvycrIs6n+IG/U9 HQWhxOSS3BabsykiLD3eBVLCFwK1Wiux+nXpfEwOYHruM49bR8OdTbaZUb4YyQ1K aatz/dHc8PjO1JGg+iSd =dodR -----END PGP SIGNATURE----- --------------enigFA60BE77987BC02D52E16480-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 05:41:37 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93E47106566B for ; Sun, 22 Jul 2012 05:41:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 502978FC08 for ; Sun, 22 Jul 2012 05:41:37 +0000 (UTC) Received: by obbun3 with SMTP id un3so9668543obb.13 for ; Sat, 21 Jul 2012 22:41:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UJ1Gu5ODJvqPGTpH0yJz4v1HHl/TdgpTIBpNqcbQwis=; b=Osz5CoPAUAgC/c8/YV54W8xZqTe/7gehuPAu+crLIXNlSNMCnSy4B8JipjzyFXLWTe phFxHMXR/1Wb2nzEyHk896LrFzDWNX+pqyuwd30/bL9peYhn4YoM+3S5ugE7P5wEkx+S AYzO8NwP6D27dvUcC04UeUceQahEJn9clE+0TnFHiq9S7nAfXyl0DTHHDqGS4GxI7tF7 abZe0srHo/TpdULM4BF3oJ0Moi2cVyB3jbfmKroxb/yOueENQDXAZLXS62TAp6M2OQ4c h9l1kTupet4sV413msRhEsACBwOqf8DaSy6O5dFXgEYrKFBaMGtWAQqNbRhDCUT2eaZA kEIw== Received: by 10.50.94.133 with SMTP id dc5mr11747660igb.16.1342935696755; Sat, 21 Jul 2012 22:41:36 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nh8sm4935829igc.1.2012.07.21.22.41.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Jul 2012 22:41:36 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 21 Jul 2012 23:41:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207212348.q6LNmjO9084188@red.freebsd.org> <201207212350.q6LNo2Lh061635@freefall.freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlliE6pc8yRl21+6bWVKz+ZlpMIDM+gcCKgwUrcnsqgHMC6J8oKZkbQCYanoCjT3mbrBSAw Cc: hackers@freebsd.org Subject: Re: kern/170058: [cbb] cardbus slot is not functioning correctly after a resume X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 05:41:37 -0000 On Jul 21, 2012, at 5:50 PM, Adrian Chadd wrote: > Hi all, >=20 > I found this in stable/9. I think it's also a problem in -HEAD. >=20 > Would someone with PCI bus clue take a look ? I'll be happy to look at it... just as soon as I get a laptop that = suspends/resumes with a cardbus slot to test it though... I have a = couple that might work, but most of them don't suspend/resume right :( Warner > Thanks! >=20 >=20 >=20 > Adrian >=20 > ---------- Forwarded message ---------- > From: > Date: 21 July 2012 16:50 > Subject: Re: kern/170058: [cbb] cardbus slot is not functioning > correctly after a resume > To: Adrian Chadd >=20 >=20 > Thank you very much for your problem report. > It has the internal identification `kern/170058'. > The individual assigned to look at your > report is: freebsd-bugs. >=20 > You can access the state of your problem report at any time > via this link: >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D170058 >=20 >> Category: kern >> Responsible: freebsd-bugs >> Synopsis: [cbb] cardbus slot is not functioning correctly after = a resume >> Arrival-Date: Sat Jul 21 23:50:02 UTC 2012 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 06:19:42 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691CA106566B for ; Sun, 22 Jul 2012 06:19:42 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 2F1628FC14 for ; Sun, 22 Jul 2012 06:19:42 +0000 (UTC) Received: (qmail 5119 invoked by uid 0); 22 Jul 2012 06:19:35 -0000 Received: from 67.206.183.191 by rms-us008 with HTTP Content-Type: text/plain; charset="utf-8" Date: Sun, 22 Jul 2012 02:19:32 -0400 From: "Dieter BSD" Message-ID: <20120722061933.298410@gmx.com> MIME-Version: 1.0 To: hackers@freebsd.org,current@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: Iv55cPUV3zOlNR3dAHAhq6p+IGRvbwAy Cc: Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 06:19:42 -0000 >>> da0: 3.300MB/s transfers >>> da0: Command Queueing enabled > > root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144 > > 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) 1) Does a larger block size (bs=1m) help? 2) That's roughly the speed I'd expect without queueing. Is it really making effective use of queueing, or is something limiting queueing to one transfer at a time? From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 07:19:19 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A34B106566B; Sun, 22 Jul 2012 07:19:19 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id F18228FC0A; Sun, 22 Jul 2012 07:19:17 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6M7JDWA003919; Sun, 22 Jul 2012 09:19:14 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6M7JDRa003916; Sun, 22 Jul 2012 09:19:13 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 22 Jul 2012 09:19:13 +0200 (CEST) From: Wojciech Puchar To: Richard Yao In-Reply-To: <500B795B.7000307@gentoo.org> Message-ID: References: <50085193.6030203@gentoo.org> <5009DB2A.7070408@gentoo.org> <500A13A6.7030503@gentoo.org> <500B795B.7000307@gentoo.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 22 Jul 2012 09:19:14 +0200 (CEST) Cc: Adrian Chadd , "hackers@FreeBSD.org" , current@freebsd.org, ivoras@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 07:19:19 -0000 > You are right. It is not capped at that speed: > > root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144 > > > > 262144+0 records in > 262144+0 records out > 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) > > you did test da1 while dmesg are about da0? is it OK and da1 is another qemu-kvm vdisk? If so, check dd if=/dev/zero of=/dev/da1 bs=512 count=256k and compare speed. i bet at something near 250kB/s and i think it is long I/O service pathlength in qemu-kvm SCSI device simulator. Just my bet i don't run FreeBSD on any VM (as opposed to running Windows under FreeBSD in VBox) check out how much CPU is used on the host side when you do that test. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 07:21:40 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36550106564A; Sun, 22 Jul 2012 07:21:40 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6578FC12; Sun, 22 Jul 2012 07:21:39 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6M7LYoV003939; Sun, 22 Jul 2012 09:21:34 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6M7LXeZ003936; Sun, 22 Jul 2012 09:21:33 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 22 Jul 2012 09:21:33 +0200 (CEST) From: Wojciech Puchar To: Dieter BSD In-Reply-To: <20120722061933.298410@gmx.com> Message-ID: References: <20120722061933.298410@gmx.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 22 Jul 2012 09:21:34 +0200 (CEST) Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 07:21:40 -0000 > > 2) That's roughly the speed I'd expect without queueing. Is it really > making effective use of queueing, or is something limiting queueing to > one transfer at a time? still 400-500 IOPS is way too little. FreeBSD without VM machine can do well over 10000 IOPS of 512 byte sequential read with single process on my laptop using less than 20% of single not blazing fast CPU. dd if=/dev/ada0 of=/dev/null bs=512 117593+0 records in 117593+0 records out 60207616 bytes transferred in 7.709451 secs (7809585 bytes/sec) CPU: Pentium(R) Dual-Core CPU T4500 @ 2.30GHz (2294.56-MHz K8-class CPU) From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 13:24:08 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B56A1065672 for ; Sun, 22 Jul 2012 13:24:08 +0000 (UTC) (envelope-from ming.zym@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF0148FC0A for ; Sun, 22 Jul 2012 13:24:07 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so9861080pbb.13 for ; Sun, 22 Jul 2012 06:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:date:content-type:x-mailer:mime-version; bh=mi2K7dpXE0NRk6/WggW6o3debMERwQmZpLOX1lmpSJg=; b=kmvEvhQsbh0Y5EK/LkWMp0wO/9nRyVmUtFH7jfnKHmpVyEsQVRlmrACOu4V9wKJo5i zNDQ9vLlBE2i9c/2PINqwoCXkzovDD04opCtYNFbzw7h5H5v7MUkr2kZtdNUbN8uSpUV /UVK0ajqr3Jd0VKMe4a4a0pN24hatHNOLShNinWMgJMbBg3BauMhDQ0ei8e+2Z5iVa+y xMl7c0YutrBzxiJAok1xlTWeNY71UMaceaaBVYzP/Weocb8bPCvC+7LFvYLrOaMnVSWo +CJycF0T3xBP3+vaGhQ92GJwuakoOftdZ6rBU/9kLq0lFFcXJMIgHe9gtYDNMUvQ1qlG taZg== Received: by 10.68.224.70 with SMTP id ra6mr27842424pbc.11.1342963447427; Sun, 22 Jul 2012 06:24:07 -0700 (PDT) Received: from [10.62.241.2] (f0-0-tep-rtr2.corp.cnb.yahoo.com. [202.43.217.166]) by mx.google.com with ESMTPS id ka5sm7923910pbb.37.2012.07.22.06.24.04 (version=SSLv3 cipher=OTHER); Sun, 22 Jul 2012 06:24:06 -0700 (PDT) Message-ID: <1342963441.4162.8.camel@zym6400> From: "ming.zym@gmail.com" To: "hackers@FreeBSD.org" Date: Sun, 22 Jul 2012 21:24:01 +0800 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-seF2u1R8aenZMW6q/M/P" X-Mailer: Evolution 3.4.3 Mime-Version: 1.0 Cc: Subject: trafficserver and raw disk access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 13:24:08 -0000 --=-seF2u1R8aenZMW6q/M/P Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apache Traffic Server may use raw disk for caching, and for privilege elevation, the worker process(traffic_server) will setuid to nobody, my question is, how to make traffic_server access the /dev/ada*? in linux, disk permitting is root:disk 0660, we can go with: 1, setup a new user 'ats', and put it into 'disk' group 2, after setuid, run initgroups() to complete the groups evn. we need a safe and easy to implement way for raw disk access in FreeBSD.=20 thanks for you help --=20 zym, Zhao Yongming. aka: yonghao @ taobao.com --=-seF2u1R8aenZMW6q/M/P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EABEIAAYFAlAL/vEACgkQQBjU8JUwVz6OfwEAhzFapWvHyC1ResMhcDLiY1ck 1PusKENuhqN60tyMiCcA+gO7ON0HPS1MLgJ6EsN9sUnZRQeZFvX/IeI+iRHPsdVT =8D/m -----END PGP SIGNATURE----- --=-seF2u1R8aenZMW6q/M/P-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 15:03:42 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06ABC1065672 for ; Sun, 22 Jul 2012 15:03:42 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE8F8FC16 for ; Sun, 22 Jul 2012 15:03:39 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6MF3YcA002655; Sun, 22 Jul 2012 17:03:34 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6MF3YmF002652; Sun, 22 Jul 2012 17:03:34 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 22 Jul 2012 17:03:34 +0200 (CEST) From: Wojciech Puchar To: "ming.zym@gmail.com" In-Reply-To: <1342963441.4162.8.camel@zym6400> Message-ID: References: <1342963441.4162.8.camel@zym6400> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 22 Jul 2012 17:03:35 +0200 (CEST) Cc: "hackers@FreeBSD.org" Subject: Re: trafficserver and raw disk access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 15:03:42 -0000 > Apache Traffic Server may use raw disk for caching, and for privilege > elevation, the worker process(traffic_server) will setuid to nobody, my > question is, how to make traffic_server access the /dev/ada*? > > in linux, disk permitting is root:disk 0660, we can go with: > 1, setup a new user 'ats', and put it into 'disk' group > 2, after setuid, run initgroups() to complete the groups evn. devfs.conf From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 16:15:31 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B021C106566C; Sun, 22 Jul 2012 16:15:31 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE6D8FC16; Sun, 22 Jul 2012 16:15:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from sage.daemoninthecloset.org (sage.daemoninthecloset.org [127.0.1.1]) by sage.daemoninthecloset.org (Postfix) with ESMTP id C3073D2CC; Sun, 22 Jul 2012 11:08:37 -0500 (CDT) Date: Sun, 22 Jul 2012 11:08:37 -0500 (CDT) From: Bryan Venteicher To: Dieter BSD Message-ID: <738102528.760.1342973317543.JavaMail.root@sage.daemoninthecloset.org> In-Reply-To: <20120722061933.298410@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - GC18 (Linux)/7.1.4_GA_2555) Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 16:15:31 -0000 ----- Original Message ----- > From: "Dieter BSD" > To: hackers@freebsd.org, current@freebsd.org > Sent: Sunday, July 22, 2012 1:19:32 AM > Subject: Re: Awful FreeBSD 9 block IO performance in KVM > > >>> da0: 3.300MB/s transfers > >>> da0: Command Queueing enabled > > > > root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 > > count=262144 > > > > 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) > > 1) Does a larger block size (bs=1m) help? > > 2) That's roughly the speed I'd expect without queueing. Is it really > making effective use of queueing, or is something limiting queueing to > one transfer at a time? The likely fix here is basically do vtblk_startio() in a separate kproc that vtblk_strategy() enqueues bio's to. This has been on my todo for a while, but haven't had the time. Also, the use of bioq_disksort() probably doesn't gain much for virtualized disks, but I never found much of a difference in my testing. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 22 17:12:27 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF3BE106564A; Sun, 22 Jul 2012 17:12:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 34A988FC08; Sun, 22 Jul 2012 17:12:26 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6MHC6wi003557; Sun, 22 Jul 2012 19:12:06 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6MHC6h3003554; Sun, 22 Jul 2012 19:12:06 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 22 Jul 2012 19:12:06 +0200 (CEST) From: Wojciech Puchar To: Bryan Venteicher In-Reply-To: <738102528.760.1342973317543.JavaMail.root@sage.daemoninthecloset.org> Message-ID: References: <738102528.760.1342973317543.JavaMail.root@sage.daemoninthecloset.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 22 Jul 2012 19:12:07 +0200 (CEST) Cc: hackers@freebsd.org, current@freebsd.org, Dieter BSD Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 17:12:27 -0000 > kproc that vtblk_strategy() enqueues bio's to. This has been on my > todo for a while, but haven't had the time. Also, the use of > bioq_disksort() probably doesn't gain much for virtualized disks, definitely. it is done by the host. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 23 01:47:31 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56E4D106566B for ; Mon, 23 Jul 2012 01:47:31 +0000 (UTC) (envelope-from ming.zym@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2368D8FC12 for ; Mon, 23 Jul 2012 01:47:31 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so10619017pbb.13 for ; Sun, 22 Jul 2012 18:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version; bh=wkOC8AVWMB5ZmFGJHHMkoSUHTMg4QPIGKnPYHXPT0yY=; b=goYhqwodtX0lQlE3KBSaflh/e8oBVwG3xIrdRobAsBmcZWA0/fwV0RJij1XFtR6p9o laZAjNOt0wiuXd+CmJ1ikxk/MR5GK6ApWQ/QCM0hMPRWvgSi7wnU+9DLnkq3Yb/xK+aH iBnnpYUcrrpO1QLmaxBYjI41FWjzxGp5wx9k3dV5Yxuo9lEcDwNobSjWee9yHLYfVrFt vzVhmyX1WxACVcjhpHlKMlfMDQrkdkxq5rA11h3FdUUiZMW98XuZ7agvAP6VSByYzHwu fvWwU7Mm59oVzmC/ljx43Hwz4cj8C8kDQmltr9Abeq62BqikBvxdckoq08veU1Orzkl3 9kJA== Received: by 10.68.225.6 with SMTP id rg6mr31652518pbc.100.1343008050854; Sun, 22 Jul 2012 18:47:30 -0700 (PDT) Received: from [10.13.237.25] ([42.120.72.160]) by mx.google.com with ESMTPS id se9sm8878300pbc.25.2012.07.22.18.47.27 (version=SSLv3 cipher=OTHER); Sun, 22 Jul 2012 18:47:29 -0700 (PDT) Message-ID: <1343008044.4047.19.camel@zym6400> From: "ming.zym@gmail.com" To: Wojciech Puchar Date: Mon, 23 Jul 2012 09:47:24 +0800 In-Reply-To: References: <1342963441.4162.8.camel@zym6400> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-+Xh3bNrkBPkV/jIpJhH4" X-Mailer: Evolution 3.4.3 Mime-Version: 1.0 Cc: "hackers@FreeBSD.org" Subject: Re: trafficserver and raw disk access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 01:47:31 -0000 --=-+Xh3bNrkBPkV/jIpJhH4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable yeah, rules in devfs always work. and it may introduce more challenge on operation management, is there any way that we can do it more clean? should we set the permission for :operator g+w on disks and partitions? then we can put a dedicate user for trafficserver into operator group. =E5=9C=A8 2012-07-22=E6=97=A5=E7=9A=84 17:03 +0200=EF=BC=8CWojciech Puchar= =E5=86=99=E9=81=93=EF=BC=9A > > Apache Traffic Server may use raw disk for caching, and for privilege > > elevation, the worker process(traffic_server) will setuid to nobody, my > > question is, how to make traffic_server access the /dev/ada*? > > > > in linux, disk permitting is root:disk 0660, we can go with: > > 1, setup a new user 'ats', and put it into 'disk' group > > 2, after setuid, run initgroups() to complete the groups evn. >=20 > devfs.conf --=20 zym, Zhao Yongming. aka: yonghao @ taobao.com --=-+Xh3bNrkBPkV/jIpJhH4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EABEIAAYFAlAMrS0ACgkQQBjU8JUwVz6xDQD/eisqDwN1fagoCPAal35AP/S+ QtcwoCusr1YHwJ8TF/wA/j8AGUAEsICExlKc9zxucK6JgEA6yaPrAPizx11BDMFc =wz0m -----END PGP SIGNATURE----- --=-+Xh3bNrkBPkV/jIpJhH4-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 23 02:19:05 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADA12106564A for ; Mon, 23 Jul 2012 02:19:05 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id EB9EF8FC0A for ; Mon, 23 Jul 2012 02:19:03 +0000 (UTC) Received: from [129.96.148.219] ([129.96.148.219]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id q6N1sohI059951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jul 2012 11:24:55 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_056321EB-8B5F-4085-9F6B-C0BA391007EC"; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <1343008044.4047.19.camel@zym6400> Date: Mon, 23 Jul 2012 11:24:46 +0930 Message-Id: <3DBCD360-4616-4EC5-B031-B70BBC79102E@gsoft.com.au> References: <1342963441.4162.8.camel@zym6400> <1343008044.4047.19.camel@zym6400> To: ming.zym@gmail.com X-Mailer: Apple Mail (2.1278) X-Spam-Score: -0.272 () BAYES_00,RDNS_NONE X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Wojciech Puchar , "hackers@FreeBSD.org" Subject: Re: trafficserver and raw disk access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 02:19:05 -0000 --Apple-Mail=_056321EB-8B5F-4085-9F6B-C0BA391007EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23/07/2012, at 11:17, ming.zym@gmail.com wrote: > yeah, rules in devfs always work. and it may introduce more challenge = on > operation management, is there any way that we can do it more clean? >=20 > should we set the permission for :operator g+w on disks and = partitions? > then we can put a dedicate user for trafficserver into operator group. I would change the ownership of the disk you want to use to = trafficserver. This does mean you have double configuration (ie in devfs and ATS) but I = think it's more sensible than giving operator write perms. AFAIK operator has read access so it can run dump. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_056321EB-8B5F-4085-9F6B-C0BA391007EC-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 23 06:56:53 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55FFC106566C for ; Mon, 23 Jul 2012 06:56:53 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 34D6C8FC08 for ; Mon, 23 Jul 2012 06:56:53 +0000 (UTC) Received: from [192.168.1.2] (pool-72-89-250-138.nycmny.fios.verizon.net [72.89.250.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id E05331B4228 for ; Mon, 23 Jul 2012 06:56:46 +0000 (UTC) Message-ID: <500CF526.7070708@gentoo.org> Date: Mon, 23 Jul 2012 02:54:30 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120628 Thunderbird/10.0.5 MIME-Version: 1.0 To: "hackers@FreeBSD.org" X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC2DFE9ECE4D88C04170F3533" Cc: Subject: Kernel thread stack size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 06:56:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2DFE9ECE4D88C04170F3533 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the default kernel thread stack size on FreeBSD? I am particularly interested in knowing about i386 and amd64, but knowing this for other architectures (such as MIPS) would also be useful. --------------enigC2DFE9ECE4D88C04170F3533 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQDPUpAAoJECDuEZm+6ExkVukP/3VXS2k7M1Temc+nPDuLyAl/ jc+0jhDy6UT/IdILxoSKQJdg+x6BkWUApuI5CAee+22r89vCDO4q1t3yPYnPqHKS 5u2YD2lDluSyBWR+JTolvGo2ggPTfniQkkFai4Ta4opmIerxh9jGzLbfT1hGV9oD Tjof+6wEJvKqe8wvg7fafhBEach6XwhJowF2UaLL9kt/mIWxABPsJ/Be6fXwis3V fSwhWzILAgjavyCGQfU3XjW3IWUH94OYFS/W/0dfOvbglcn4Lv/XSBHeb2nRPbZd vVsG4KgYTEF2KOLQe4c1tnfowl8y8OkKlHZhauc1JWxYc/fmBUSAHnCabud5C2LD xV9OEAObeAG0lZrzYSUiEDr/snWcZp3h50LifHmK09hMna+mACBHswzuFU5V1FAu /Yo1JYizZ2CvwDkRXHlvqkEqo7znGB523B9KptfAf8hk2M78ZUHIjI1owoNTtnpa +49YRhR4PqC7InibgM4vTpkkBpD4MtF9ygJXkvtTv7j5MW1/2Bvvo0j24UZmYvPl mJta6AyPHBL1COYWv7MBWVT3ho3EHg6olWbmey7bUk+tLYfDHFBvbAmnxcm41twz kHQAUHvSEQdEjgAzzC5OhFzr9tMEPHedADVMPRrNH9ZdmnZ5cByKIQsh0pcnfalj RHEKqU6QAhTKqriohtkB =ak47 -----END PGP SIGNATURE----- --------------enigC2DFE9ECE4D88C04170F3533-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 23 07:41:50 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF4BF1065678 for ; Mon, 23 Jul 2012 07:41:50 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 203CC8FC22 for ; Mon, 23 Jul 2012 07:41:49 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6N7fmBT007650; Mon, 23 Jul 2012 09:41:49 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6N7fmcc007647; Mon, 23 Jul 2012 09:41:48 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 23 Jul 2012 09:41:48 +0200 (CEST) From: Wojciech Puchar To: "ming.zym@gmail.com" In-Reply-To: <1343008044.4047.19.camel@zym6400> Message-ID: References: <1342963441.4162.8.camel@zym6400> <1343008044.4047.19.camel@zym6400> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 23 Jul 2012 09:41:49 +0200 (CEST) Cc: "hackers@FreeBSD.org" Subject: Re: trafficserver and raw disk access in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:41:50 -0000 > yeah, rules in devfs always work. and it may introduce more challenge on > operation management, is there any way that we can do it more clean? what challenges? > > should we set the permission for :operator g+w on disks and partitions? you still may just do chown/chmod > then we can put a dedicate user for trafficserver into operator group. > > > ? 2012-07-22?? 17:03 +0200?Wojciech Puchar??? >>> Apache Traffic Server may use raw disk for caching, and for privilege >>> elevation, the worker process(traffic_server) will setuid to nobody, my >>> question is, how to make traffic_server access the /dev/ada*? >>> >>> in linux, disk permitting is root:disk 0660, we can go with: >>> 1, setup a new user 'ats', and put it into 'disk' group >>> 2, after setuid, run initgroups() to complete the groups evn. >> >> devfs.conf > > -- > zym, Zhao Yongming. > aka: yonghao @ taobao.com > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 23 08:17:12 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3ED6106566B for ; Mon, 23 Jul 2012 08:17:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 289938FC0C for ; Mon, 23 Jul 2012 08:17:11 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6N8GxcX093817; Mon, 23 Jul 2012 11:16:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6N8GkIg034868; Mon, 23 Jul 2012 11:16:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6N8GkWe034867; Mon, 23 Jul 2012 11:16:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jul 2012 11:16:46 +0300 From: Konstantin Belousov To: Richard Yao Message-ID: <20120723081646.GN2676@deviant.kiev.zoral.com.ua> References: <500CF526.7070708@gentoo.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CSGWCrCVWDYEEUXI" Content-Disposition: inline In-Reply-To: <500CF526.7070708@gentoo.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "hackers@FreeBSD.org" Subject: Re: Kernel thread stack size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:17:12 -0000 --CSGWCrCVWDYEEUXI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote: > What is the default kernel thread stack size on FreeBSD? I am > particularly interested in knowing about i386 and amd64, but knowing > this for other architectures (such as MIPS) would also be useful. >=20 Look for the KSTACK_PAGES symbol defined in sys//include/param.h. It defines _default_ number of pages allocated for kernel stack of new thread. We have 4 pages for amd64, and 2 pages for i386, AFAIR. Look up the MIPS yourself. --CSGWCrCVWDYEEUXI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlANCG4ACgkQC3+MBN1Mb4gcTQCeM+cc+DsxVNlm3rTz4D3xITwN PX4AoPA1tvBNmMZbS0k2MStJAQ7PcfPi =DDli -----END PGP SIGNATURE----- --CSGWCrCVWDYEEUXI-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 24 18:18:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFE21065678; Tue, 24 Jul 2012 18:18:29 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCB328FC17; Tue, 24 Jul 2012 18:18:28 +0000 (UTC) Received: by weyx56 with SMTP id x56so6393104wey.13 for ; Tue, 24 Jul 2012 11:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5yPXMt57VKKDGr2n4lrETE0gqk+WFMPKx9D932NKZoM=; b=JaGAzk7/LdBaVT0OdN8HwxNHjHu3ufducSkjyYwjKqqL7nP129agDNbcb8Y2vmtGwG d2vQ1nLKlgS6WOL/AckdP7FjRdrzo3Io6RIhgAAkaIJMTC8GHwpGYGval8hdYqOo7LTr ugEgKq+Gs3m6aWlfH6DdhJ9G04MZ043/ao6LqK5r/cPCA48vTVYodm1g/pW7JeWLAaxP HfCE7tyh1sJn+jaLWhzYWco+qDNR3JP3kYTM143XGwGLtxempiU1hRFmRUluRpLQi3fp ynkRyIJdUgNtU9XwT012l844Wq4C5BF2tIHnduK/S4BTkO1fHZ+GY5C7SiTIBSkh+ZPc WuUA== MIME-Version: 1.0 Received: by 10.180.78.33 with SMTP id y1mr9232694wiw.3.1343153907921; Tue, 24 Jul 2012 11:18:27 -0700 (PDT) Received: by 10.216.79.81 with HTTP; Tue, 24 Jul 2012 11:18:27 -0700 (PDT) Date: Tue, 24 Jul 2012 14:18:27 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Net Content-Type: multipart/mixed; boundary=f46d043bdec88f754c04c5976376 Cc: FreeBSD Hackers Subject: Generic queue's KPI to manipulate mbuf's queue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:18:29 -0000 --f46d043bdec88f754c04c5976376 Content-Type: text/plain; charset=ISO-8859-1 Hi, AFAIK, there is no proper KPI for managing mbuf queue. All users have to re-implements the queue logic from scratch, which is less than optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do not need a new list implementation". There has been a few attempt of providing a queue API, namely , but that is nothing more than an ad-hoc solution to something which _has_to_be_ generic. For the sake of adding more mess in the tree, this implementation has been duplicated in ... Now, I understand, or at least merely witness without power, the reluctance of kernel hackers to have 'struct mbuf` evolves, especially wrt. their desire to keep binary compatibility of KPI[0]. Now, none of the current ad-hoc API matched my needs, and I really did NOT want to re-implement a new list implementation for missing basic operation, such as deleting an element of the list, so I came with the attached patch. The main idea is to be able to use already existing code from for mbuf queuing management. It is not the best which can be done. I am not a huge fan of keeping `m_nextpkt' and introducing a `m_nextelm', I would have preferred to use TAILQs, and I do not like the dwelling in SLIST internal implementation details. However, this change is relatively lightweight, and change neither ABI or API. Any comment appreciated. - Arnaud [0]: taking care of having a stable kernel ABI and *not* a stable userland ABI is beyond my understanding, but this is not the subject of this mail. --f46d043bdec88f754c04c5976376 Content-Type: application/octet-stream; name="mbuf_slist.diff" Content-Disposition: attachment; filename="mbuf_slist.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h51aq8mx0 ZGlmZiAtLWdpdCBhL2ZyZWVic2Qvc3lzL3N5cy9tYnVmLmggYi9mcmVlYnNkL3N5cy9zeXMvbWJ1 Zi5oCmluZGV4IDkwN2I3N2EuLmVhOWFmZWIgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvbWJ1Zi5oCisr KyBiL3N5cy9zeXMvbWJ1Zi5oCkBAIC04OCw3ICs4OCw3IEBAIHN0cnVjdCBtYl9hcmdzIHsKICAq Lwogc3RydWN0IG1faGRyIHsKIAlzdHJ1Y3QgbWJ1ZgkqbWhfbmV4dDsJLyogbmV4dCBidWZmZXIg aW4gY2hhaW4gKi8KLQlzdHJ1Y3QgbWJ1ZgkqbWhfbmV4dHBrdDsJLyogbmV4dCBjaGFpbiBpbiBx dWV1ZS9yZWNvcmQgKi8KKwlTTElTVF9FTlRSWShtYnVmKSBtaF9uZXh0cGt0OwkvKiBuZXh0IGNo YWluIGluIHF1ZXVlL3JlY29yZCAqLwogCWNhZGRyX3QJCSBtaF9kYXRhOwkvKiBsb2NhdGlvbiBv ZiBkYXRhICovCiAJaW50CQkgbWhfbGVuOwkvKiBhbW91bnQgb2YgZGF0YSBpbiB0aGlzIG1idWYg Ki8KIAlpbnQJCSBtaF9mbGFnczsJLyogZmxhZ3M7IHNlZSBiZWxvdyAqLwpAQCAtMTU5LDcgKzE1 OSw4IEBAIHN0cnVjdCBtYnVmIHsKICNkZWZpbmUJbV9kYXRhCQltX2hkci5taF9kYXRhCiAjZGVm aW5lCW1fdHlwZQkJbV9oZHIubWhfdHlwZQogI2RlZmluZQltX2ZsYWdzCQltX2hkci5taF9mbGFn cwotI2RlZmluZQltX25leHRwa3QJbV9oZHIubWhfbmV4dHBrdAorI2RlZmluZQltX25leHRwa3QJ bV9oZHIubWhfbmV4dHBrdC5zbGVfbmV4dAorI2RlZmluZQltX25leHRlbG0JbV9oZHIubWhfbmV4 dHBrdAogI2RlZmluZQltX2FjdAkJbV9uZXh0cGt0CiAjZGVmaW5lCW1fcGt0aGRyCU1fZGF0Lk1I Lk1IX3BrdGhkcgogI2RlZmluZQltX2V4dAkJTV9kYXQuTUguTUhfZGF0Lk1IX2V4dAo= --f46d043bdec88f754c04c5976376-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 24 23:45:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66724106566C for ; Tue, 24 Jul 2012 23:45:29 +0000 (UTC) (envelope-from raysonlogin@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4478FC0A for ; Tue, 24 Jul 2012 23:45:29 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so413267pbb.13 for ; Tue, 24 Jul 2012 16:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+feUWoPi7bOSDLXNnkV/o1H18EoJ5zxhGWrr4BLdtC4=; b=tNaP4/vVhjDYzehp8cPgeDEUyQrU5+WUXBLL/zKy0tgd0rR0KHmH5kiSEda+rhDmRz ipkNCQGI3HpUsNpWSKBbZ+dHZvlw/+NMQCZgEPZj7DIzFbYGrKnuPsuSHxYcm4wL9Kgh 5kVgPeDq0riNzyaRuAiPZapQHK0zCYCp9ypkX147tAkQm/oSp1jW276USfgo+S9g6hxp 6qsC31MRJ9BFTuIuqtzAx0UuVXDtsSL2VlDxuELGdpytE83CcB8WPnvNupXnaRhBPoSK dWwZw9jdUWsvvTkLpTit+clA5iT6utBfGxpgQ2YTRGECIZN35zDZW4Ij/Kr1fALDaPXM Dysw== MIME-Version: 1.0 Received: by 10.68.135.201 with SMTP id pu9mr48109508pbb.146.1343173528968; Tue, 24 Jul 2012 16:45:28 -0700 (PDT) Received: by 10.68.10.136 with HTTP; Tue, 24 Jul 2012 16:45:28 -0700 (PDT) Date: Tue, 24 Jul 2012 19:45:28 -0400 Message-ID: From: Rayson Ho To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: libdwarf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 23:45:29 -0000 Hi, I need some changes in libdwarf, and I was wondering where I can discuss & ask devel related questions. The original maintainer was John Birrell, who left us in 2009: https://blogs.oracle.com/bmc/entry/john_birrell Rayson From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 00:40:39 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F3E7106564A for ; Wed, 25 Jul 2012 00:40:39 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4BA8FC0A for ; Wed, 25 Jul 2012 00:40:38 +0000 (UTC) Received: by weyx56 with SMTP id x56so134390wey.13 for ; Tue, 24 Jul 2012 17:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zXKuHId0UVo+I9GMQ8B3BjhzW/VOb7+ftyb7EpNBERQ=; b=ifW5gxER9FlvoCV3ZBZ2rKH4WSDI++wPg0oIl54wbei6J2JVECqyL5OwgogK9DqO3W Asytp97iRSVZDoc8l3F32dvwQZj3G8wy9YGB8XSl/pqdszLCou/CbsO3xYAIwIh39hwU QlaSCCfq1fqS9HwMDNuvrSewh/ih9thrlshQP9bo6PIacYKJvENHfBZ+E5CaX7UE2jZH rZkTIhEwxlXXENWJQJ82RcTzMgq3aSvc0esD1KWgawSL7AlBwGlh7HLJTRoQO6L103h+ 3QJvIU0EGRHUvdrRRTEHisJ0dfDbyasuc+54DK40mynRHowKkGwn4Gkg0CesDHZxFa8t u/Dw== MIME-Version: 1.0 Received: by 10.180.87.232 with SMTP id bb8mr11818798wib.0.1343176838044; Tue, 24 Jul 2012 17:40:38 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Tue, 24 Jul 2012 17:40:37 -0700 (PDT) In-Reply-To: <20120723081646.GN2676@deviant.kiev.zoral.com.ua> References: <500CF526.7070708@gentoo.org> <20120723081646.GN2676@deviant.kiev.zoral.com.ua> Date: Wed, 25 Jul 2012 08:40:37 +0800 Message-ID: From: Paul Ambrose To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Richard Yao , "hackers@FreeBSD.org" Subject: Re: Kernel thread stack size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 00:40:39 -0000 #define PAGE_SHIFT 12 #define PAGE_SIZE (1< > On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote: > > What is the default kernel thread stack size on FreeBSD? I am > > particularly interested in knowing about i386 and amd64, but knowing > > this for other architectures (such as MIPS) would also be useful. > > > > Look for the KSTACK_PAGES symbol defined in sys//include/param.h. > It defines _default_ number of pages allocated for kernel stack of > new thread. > > We have 4 pages for amd64, and 2 pages for i386, AFAIR. Look up the MIPS > yourself. > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 03:22:00 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA468106566B for ; Wed, 25 Jul 2012 03:22:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9425D8FC08 for ; Wed, 25 Jul 2012 03:22:00 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so698789pbb.13 for ; Tue, 24 Jul 2012 20:22:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FIU594dX8hz5ddKLxGLQWVhimkBtnRjia690J8/vHhQ=; b=chpvi6ilBJDApvKZyZF6SkLDL3XU9t8QIZrkqyLM17SxlIsct8mlXI828XALbyoxQm hNaadN4tE56cECRUS7k01b2OgrowA0svaQar9lL1dzKJzs7oDKyqyosltPMpX8+QSVMr CNK7JxJQkheerAF5+G417a5ZZDsWT08yfWEWtVwVpLaqQ85+TkN4Dx6dz87rEDXJwvvZ 4F01KVPq9swUumNKPjhxRnLT4+ZGQ42H1/XoOg+fszxEwWEGX2QJzq3FYwNGaJ9hF+ia MNFJ2dld5IUE+fobCkjdI7h2FbiOl0wd3uUDO6++HrXq68pJ2B7IiJu2N1Sjd0v99qfl 45tg== Received: by 10.68.212.70 with SMTP id ni6mr49767103pbc.22.1343186520155; Tue, 24 Jul 2012 20:22:00 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id og4sm13413013pbb.48.2012.07.24.20.21.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jul 2012 20:21:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 24 Jul 2012 21:21:56 -0600 Content-Transfer-Encoding: 7bit Message-Id: <2177D7D9-A2F6-4CF0-BAF6-5018CD8A2374@bsdimp.com> References: <500CF526.7070708@gentoo.org> <20120723081646.GN2676@deviant.kiev.zoral.com.ua> To: Paul Ambrose X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmdIrPyba/XKZA3AK3hN51ETc9zJHImW2Ze6aJtT1aMnJuUAxA4WJfJtZzmj7YJXdqekq/k Cc: Konstantin Belousov , Richard Yao , "hackers@FreeBSD.org" Subject: Re: Kernel thread stack size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 03:22:00 -0000 On Jul 24, 2012, at 6:40 PM, Paul Ambrose wrote: > #define PAGE_SHIFT 12 > #define PAGE_SIZE (1< > #define KSTACK_PAGES 2 > #define KSTACK_GUARD_PAGES 2 > > I had a MIPS machine (Loongson 3A) with page size 16KB( could be 4KB, but > had to handle cache alias in OS), IMHO, define KSTACK_PAGE to 1 is enough, > what is your opinion? Well, the PTE has two entries, so having just one page would be inefficient. Warner > 2012/7/23 Konstantin Belousov > >> On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote: >>> What is the default kernel thread stack size on FreeBSD? I am >>> particularly interested in knowing about i386 and amd64, but knowing >>> this for other architectures (such as MIPS) would also be useful. >>> >> >> Look for the KSTACK_PAGES symbol defined in sys//include/param.h. >> It defines _default_ number of pages allocated for kernel stack of >> new thread. >> >> We have 4 pages for amd64, and 2 pages for i386, AFAIR. Look up the MIPS >> yourself. >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 06:25:10 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9C921065670 for ; Wed, 25 Jul 2012 06:25:10 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55DB08FC0C for ; Wed, 25 Jul 2012 06:25:10 +0000 (UTC) Received: by weyx56 with SMTP id x56so296658wey.13 for ; Tue, 24 Jul 2012 23:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a7kYwuX0wmS6XgbBc0XC8esQ1X3c3pB/wTdNFoHI5ms=; b=RtBGn6KmnBsVjjB/128Xmn5bdNySwxyn4Y/yTTV8GtLKI59zJ0oF8b85X+QymRaZFi nw7KNU1BQlhB42kSLI+5AaZTFQ5LVZTYzgVuM759YLuglVQSycZT1IKEIhXaHNZ4zUEC AoQzwXrEj4ORP5sPu6VJeWDA3WriIq3uKts4RvaQt6rglmcZupilHhUXTLsfLpBCwtzb 7T1qx4jMZ65UhrPkPnTteVC3GrHz+oiWXwaNqlSAZAHuTj/PcCdEpj16OXyB1QYntA+H ZiP5xiUUeuJv/Qory/sRFb3Ty3F/trTtph5ydOYwp++N+gzYhJbe3G8hdnuFOdhMyt3h PL6Q== MIME-Version: 1.0 Received: by 10.216.27.7 with SMTP id d7mr1612082wea.187.1343197509442; Tue, 24 Jul 2012 23:25:09 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Tue, 24 Jul 2012 23:25:09 -0700 (PDT) Received: by 10.223.144.216 with HTTP; Tue, 24 Jul 2012 23:25:09 -0700 (PDT) In-Reply-To: <2177D7D9-A2F6-4CF0-BAF6-5018CD8A2374@bsdimp.com> References: <500CF526.7070708@gentoo.org> <20120723081646.GN2676@deviant.kiev.zoral.com.ua> <2177D7D9-A2F6-4CF0-BAF6-5018CD8A2374@bsdimp.com> Date: Wed, 25 Jul 2012 14:25:09 +0800 Message-ID: From: Paul Ambrose To: Warner Losh Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Konstantin Belousov , Richard Yao , "hackers@FreeBSD.org" Subject: Re: Kernel thread stack size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 06:25:10 -0000 Could you be more specific about "inefficient"=A3=BF =D4=DA 2012-7-25 =C9=CF=CE=E711:22=A3=AC"Warner Losh" =D0= =B4=B5=C0=A3=BA > > > On Jul 24, 2012, at 6:40 PM, Paul Ambrose wrote: > > > #define PAGE_SHIFT 12 > > #define PAGE_SIZE (1< > > > #define KSTACK_PAGES 2 > > #define KSTACK_GUARD_PAGES 2 > > > > I had a MIPS machine (Loongson 3A) with page size 16KB( could be 4KB, but > > had to handle cache alias in OS), IMHO, define KSTACK_PAGE to 1 is enough, > > what is your opinion? > > Well, the PTE has two entries, so having just one page would be inefficient. > > Warner > > > 2012/7/23 Konstantin Belousov > > > >> On Mon, Jul 23, 2012 at 02:54:30AM -0400, Richard Yao wrote: > >>> What is the default kernel thread stack size on FreeBSD? I am > >>> particularly interested in knowing about i386 and amd64, but knowing > >>> this for other architectures (such as MIPS) would also be useful. > >>> > >> > >> Look for the KSTACK_PAGES symbol defined in sys//include/param.h= . > >> It defines _default_ number of pages allocated for kernel stack of > >> new thread. > >> > >> We have 4 pages for amd64, and 2 pages for i386, AFAIR. Look up the MIPS > >> yourself. > >> > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " freebsd-hackers-unsubscribe@freebsd.org" > could you be more specific about "inefficient"=A3=BF From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 10:26:22 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C3A106566C; Wed, 25 Jul 2012 10:26:22 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 090DB8FC17; Wed, 25 Jul 2012 10:26:22 +0000 (UTC) Received: from [192.168.1.2] (pool-72-89-250-138.nycmny.fios.verizon.net [72.89.250.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id CAF471B4678; Wed, 25 Jul 2012 10:26:20 +0000 (UTC) Message-ID: <500FC945.8010602@gentoo.org> Date: Wed, 25 Jul 2012 06:24:05 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120628 Thunderbird/10.0.5 MIME-Version: 1.0 To: Wojciech Puchar References: <50085193.6030203@gentoo.org> <5009DB2A.7070408@gentoo.org> <500A13A6.7030503@gentoo.org> <500B795B.7000307@gentoo.org> <63653b2570964cb995f7191fabdb52c8@HUBCAS2.cs.stonybrook.edu> In-Reply-To: <63653b2570964cb995f7191fabdb52c8@HUBCAS2.cs.stonybrook.edu> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F1E5AD08EEA7A960EB00674" Cc: Richard Yao , "hackers@FreeBSD.org" , "ivoras@freebsd.org" , Adrian Chadd , "current@freebsd.org" Subject: Re: Awful FreeBSD 9 block IO performance in KVM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:26:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F1E5AD08EEA7A960EB00674 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/22/2012 03:19 AM, Wojciech Puchar wrote: >> You are right. It is not capped at that speed: >> >> root@freebsd:/root # dd if=3D/dev/zero of=3D/dev/da1 bs=3D16384 count=3D= 262144 >> >> >> >> 262144+0 records in >> 262144+0 records out >> 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) >> >> > you did test da1 while dmesg are about da0? >=20 > is it OK and da1 is another qemu-kvm vdisk? >=20 > If so, check >=20 > dd if=3D/dev/zero of=3D/dev/da1 bs=3D512 count=3D256k >=20 > and compare speed. >=20 > i bet at something near 250kB/s and i think it is long I/O service=20 > pathlength in qemu-kvm SCSI device simulator. >=20 > Just my bet i don't run FreeBSD on any VM (as opposed to running Window= s=20 > under FreeBSD in VBox) >=20 > check out how much CPU is used on the host side when you do that test. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" The test was on da1, but that does not explain how Linux manages to get over 100MB/s when writing to a file on ext4. I will do some more comprehensive tests as soon as I find time. --------------enig7F1E5AD08EEA7A960EB00674 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQD8lIAAoJECDuEZm+6Exk+DsP/jvqXUDEBlglCP79abNDJ3zy F/Au0LCk8ylgQwvNbS5vRJy0lMpfYZKjywNh/8A84b9kfqcshmpFZdwoiOyM/Z5X i3iuQTwwbXIQ91C53fE9wSfK2bmoXBM+zbLPMmaLw1qklk9H8/JGnAVT8UvyS+SW lAVUVO25NDsKoJT6Yh/S1xqdaUGpGIsjBqKxl6S4ZvWuamb7ZHoHUuRithwRWRRF GzfKky1FZ/gTRC5TLXXgaaXN9xpDz0O7mmCYvmNI/2JE9L9LgxP+zq5edpyIJ1ch bOcmjegbJ1i77D+6v+8kPg6HLFw97MUJqGczq1IbEcliWlWBBjlBHe0hwoOi2ARD gD4/v7OKmnOJb2dZEthOI/EF6bwWEE6EWhmT+/XRf3oGrgxf6ZtTmK9hLu95wDbn OTLQyNPHB88yJCLsyHuDKut9Ny7pph3hDBQHACPmy9MmQHvW8/RIIORBIfGz+T5/ ddcnLno4HXkIRtkewmiJUApkjUq+fSdchEYu2DzrgKvNvWkAP/vSBNYq6IWnD3Nf P8NPoADV/VxB2rQwvrTqJboRbH7bXik2fqbAMerUHmek0BcszS0P6o0Xr2YEEK+R uD3ov/Yb9332HD0aBsMiAWrn08eiFiz9diSf7Jgwlm/2AvXFW5GYmBznuSENP6oK mku1FyTDw336awa/sWea =V+nb -----END PGP SIGNATURE----- --------------enig7F1E5AD08EEA7A960EB00674-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 11:26:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBC3E1065670 for ; Wed, 25 Jul 2012 11:26:53 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD998FC08 for ; Wed, 25 Jul 2012 11:26:53 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q6PBPiaN051361; Wed, 25 Jul 2012 12:25:44 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Bob Bishop In-Reply-To: Date: Wed, 25 Jul 2012 12:25:38 +0100 Content-Transfer-Encoding: 7bit Message-Id: <69BD68D0-D5CA-4512-BAD2-E7C7D9E58B81@gid.co.uk> References: To: Rayson Ho X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@freebsd.org Subject: Re: libdwarf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:26:54 -0000 Hi, On 25 Jul 2012, at 00:45, Rayson Ho wrote: > Hi, > > I need some changes in libdwarf, and I was wondering where I can > discuss & ask devel related questions. You should ask on the dwarf-discuss list, see http://dwarfstd.org/ > The original maintainer was John Birrell, who left us in 2009: > https://blogs.oracle.com/bmc/entry/john_birrell > > Rayson -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 11:32:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ABB7106566B for ; Wed, 25 Jul 2012 11:32:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 922FA8FC0A for ; Wed, 25 Jul 2012 11:32:32 +0000 (UTC) Received: (qmail 83650 invoked from network); 25 Jul 2012 13:20:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jul 2012 13:20:14 -0000 Message-ID: <500FD7B9.4070804@freebsd.org> Date: Wed, 25 Jul 2012 13:25:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , FreeBSD Hackers Subject: Re: Generic queue's KPI to manipulate mbuf's queue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 11:32:33 -0000 On 24.07.2012 20:18, Arnaud Lacombe wrote: > Hi, > > AFAIK, there is no proper KPI for managing mbuf queue. All users have Before we can talk about an mbuf queue you have to define what you want to "queue". Is it packets or an mbuf chain which doesn't have clear delimiters (as with tcp for example)? Depending on that the requirements and solutions may be vastly different. > to re-implements the queue logic from scratch, which is less than > optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do > not need a new list implementation". There has been a few attempt of > providing a queue API, namely , but that is > nothing more than an ad-hoc solution to something which _has_to_be_ > generic. For the sake of adding more mess in the tree, this > implementation has been duplicated in ... Duplication is always a sign for the need of a generic approach/KPI. > Now, I understand, or at least merely witness without power, the > reluctance of kernel hackers to have 'struct mbuf` evolves, especially > wrt. their desire to keep binary compatibility of KPI[0]. Now, none of > the current ad-hoc API matched my needs, and I really did NOT want to > re-implement a new list implementation for missing basic operation, > such as deleting an element of the list, so I came with the attached > patch. The main idea is to be able to use already existing code from > for mbuf queuing management. It is not the best which > can be done. I am not a huge fan of keeping `m_nextpkt' and > introducing a `m_nextelm', I would have preferred to use TAILQs, and I > do not like the dwelling in SLIST internal implementation details. > However, this change is relatively lightweight, and change neither ABI > or API. IMO your change is a rather elegant way of introducing the LIST macros to the mbuf nextpkt field. I do like it and don't object to it providing you sufficiently answer the question in the first paragraph. -- Andre > Any comment appreciated. > > - Arnaud > > [0]: taking care of having a stable kernel ABI and *not* a stable > userland ABI is beyond my understanding, but this is not the subject > of this mail. > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 12:49:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76434106564A for ; Wed, 25 Jul 2012 12:49:45 +0000 (UTC) (envelope-from bfalk_bsd@brandonfa.lk) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 299728FC12 for ; Wed, 25 Jul 2012 12:49:45 +0000 (UTC) Received: by yhfs35 with SMTP id s35so751512yhf.13 for ; Wed, 25 Jul 2012 05:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brandonfa.lk; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=J3YM2u/10R62hHYm6qBhYk3DarLuFde/H8rH+9YfDP8=; b=J2jPRjj6O9kvE9X1zvQnPTPsw8DZ26+dSBQ6f4tKv8cYOwlKL+NpAjMJMet1nt9ynU 2fNF8oNmMRboIfRo5upFpNNnTNYiX+rIU2PkCjjCGqdlKs2CGaPmzNUSI7qb7uri0Rq6 E046wrkwz9P4gMaIAO7R5URfFHDLXuNJuJBqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=J3YM2u/10R62hHYm6qBhYk3DarLuFde/H8rH+9YfDP8=; b=nRKNWTNtOPHGnXDpDmpi1ROQLm9UCqKP2OMIH4W0njJATnxBHEwZ0ksiYJjJK/a5Kk L3VbHO0MduCGmggapC2RFF5MMWKwj7b8Eu4L52vu8zloaQpONOJWrMSrc58Nzuz5USlV F3Vzxr6FD445AMw3m+XzCXRTxPUMApoMOsoHcyUKCV/bsN9wNfxDdFhZjeQ1tmL755XB 6I+nee3tLQGkkKocDF670ZOS5DMFtuc14uxm5SF2JmGK241KsJnku8cIj6LTvykCpgku XHs+vHteyZnpMkXvSzTRq6qyXSPxG0XKNz2oWauNQQisZHFdE35PwpTkU4niO6BDy1SE KJxA== MIME-Version: 1.0 Received: by 10.42.197.197 with SMTP id el5mr24613850icb.35.1343220584280; Wed, 25 Jul 2012 05:49:44 -0700 (PDT) Received: by 10.231.16.203 with HTTP; Wed, 25 Jul 2012 05:49:44 -0700 (PDT) X-Originating-IP: [72.83.231.212] Date: Wed, 25 Jul 2012 08:49:44 -0400 Message-ID: From: Brandon Falk To: freebsd-hackers@freebsd.org X-Gm-Message-State: ALoCoQnsLvo61An8BvH1fwiyrudVGFotTaWDaqZfg6ak86FEKIaDf+CAC6xmkwXVb253D/I9rrbJ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Pre-make and Post-make scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 12:49:45 -0000 I'm curious as to how the best way of having a script run before and after make would be done. Would this require modification of the FreeBSD make template, or is this functionality already built in? The goal of this is to set up a script that prior to a build sends up a filesystem in ram (tmpfs) for the build to occur in, and afterwards saves the filesystem from ram onto the actual disk for backup/archiving. We all know that our poor disks could use a little break from the strain of build processes. -Brandon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 16:02:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C81C4106564A for ; Wed, 25 Jul 2012 16:02:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D73E8FC0C for ; Wed, 25 Jul 2012 16:02:56 +0000 (UTC) Received: by obbun3 with SMTP id un3so1647741obb.13 for ; Wed, 25 Jul 2012 09:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tie4r6D6/UI5nH5ttjCcdTbk8bhlvHksO01O1K2Jk2s=; b=gg5mzjDCplEPk+ZGrYwFGT/rGhhuPSLQK6MTiIITS8uVgPGqVNYQkd2HuWa6FCdTI/ ne4hOJrch+C2ZQIay+SW3awMP3je+UK0Q+aCJKllijrLmsvcRu2VqPJIjS3o39O0Bicm qLVEhR/gXcBWzkFHFRUlZhV53PzUfVE+jkpqrXgaIOYBYCQ2yabYlQX4xVjHFBmEHG+E S07neMrn8/43vsGKcB0bM14fbBUv+1Tj/oWEUw4otz0jz/RT3JQfPhluwEjN5d3lHW90 xRJ5BJWhnryiBSMLOVeLAZZNcw7qT8eJ3VRxqqP0MXu88qDzNt6KXgAHwr8wXl6N6mFz ip3A== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr18439565oba.39.1343232175984; Wed, 25 Jul 2012 09:02:55 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Wed, 25 Jul 2012 09:02:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Jul 2012 09:02:55 -0700 Message-ID: From: Garrett Cooper To: Brandon Falk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Pre-make and Post-make scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:02:58 -0000 On Wed, Jul 25, 2012 at 5:49 AM, Brandon Falk wrote: > I'm curious as to how the best way of having a script run before and after > make would be done. Would this require modification of the FreeBSD make > template, or is this functionality already built in? > > The goal of this is to set up a script that prior to a build sends up a > filesystem in ram (tmpfs) for the build to occur in, and afterwards saves > the filesystem from ram onto the actual disk for backup/archiving. We all > know that our poor disks could use a little break from the strain of build > processes. Or just mount MAKEOBJDIRPREFIX (defaults to /usr/obj) in a swap backed disk / tmpfs? Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 18:09:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05A0E106566B for ; Wed, 25 Jul 2012 18:09:11 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 34CC08FC17 for ; Wed, 25 Jul 2012 18:09:09 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q6PI95s6009585; Wed, 25 Jul 2012 20:09:06 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q6PI95aO009582; Wed, 25 Jul 2012 20:09:05 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 25 Jul 2012 20:09:05 +0200 (CEST) From: Wojciech Puchar To: Garrett Cooper In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 25 Jul 2012 20:09:06 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Brandon Falk Subject: Re: Pre-make and Post-make scripts X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:09:11 -0000 > > Or just mount MAKEOBJDIRPREFIX (defaults to /usr/obj) in a swap > backed disk / tmpfs? i just do this. From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 20:27:53 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B709106566B; Wed, 25 Jul 2012 20:27:53 +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 56EB68FC14; Wed, 25 Jul 2012 20:27:52 +0000 (UTC) Received: from porto.starpoint.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 XAA22830; Wed, 25 Jul 2012 23:27:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Su8BS-000934-4E; Wed, 25 Jul 2012 23:27:50 +0300 Message-ID: <501056C4.3080806@FreeBSD.org> Date: Wed, 25 Jul 2012 23:27:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 20:27:53 -0000 Preamble. I am trying to understand in detail how things work at GEOM <-> "CAM disk" boundary. I am looking at scsi_da and ata_da which seem to be twins in this respect. I got an impression that the bioq_disksort calls in the strategy methods and the related queues are completely useless in the GEOM single-threaded world. There is only one thread, g_down, that can call a strategy method, the method enqueues a bio, then calls a schedule function and through xpt_schedule the call flow continues to a start method which dequeues the bio and off it goes. I currently can see how a bio queue can accumulate more than one bio. What am I missing? :-) I will be very glad to learn more about this layer if anyone is willing to educate me. Thank you in advance. P.S. I wrote a very simple to DTrace script to my "theory" experimentally and my testing with various workloads didn't disprove the theory so far (which doesn't mean that it is correct, of course). The script: fbt::bioq_disksort:entry /args[0]->queue.tqh_first == 0/ { @["empty"] = count(); } fbt::bioq_disksort:entry /args[0]->queue.tqh_first != 0/ { @["non-empty"] = count(); } It works on all bioq_disksort calls, but I stressing only ada disks at the moment. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 22:07:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28E09106564A; Wed, 25 Jul 2012 22:07:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 36DE48FC0C; Wed, 25 Jul 2012 22:07:19 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1164488wgb.31 for ; Wed, 25 Jul 2012 15:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xCjRclWupUBbHNW28bshcuJldym+nph0RS8wi0HH9UM=; b=ULFogl4bT0/BjFx1VnUjvWWa1w2ihMH21rpgcF331r7/H7Q1PlCqQZ2elhO8yZYauG j9VsRMyoFL8ixWtPDTk/FF8mG8mwSZV2b0C/uiz0d/xXlKdBzoppGZT9ZrI5u5xtuSbB EYeyvurVb/Z9ESA7plDv5aITI8s54fvIdPx64vs+e47a3oQ9sj0bcoroKIY4dN9zs78n uZH2VHKpiSeTxIWk2mYUSR7qu8UC9Vv2wYlCbn9ftOHvNL6dRnrWGWLHDKJUkE08MVtJ ZuyyIVOo1mFyxy6ObaFiiyKC2EQT7EEYe3uQwVhPv7Hk0CdtzMvSw7m1vDkzOPe91x7t 1kKA== Received: by 10.180.78.4 with SMTP id x4mr8035938wiw.19.1343254038100; Wed, 25 Jul 2012 15:07:18 -0700 (PDT) Received: from pc.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id bc2sm7301435wib.0.2012.07.25.15.07.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 15:07:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <50106E5F.4030402@FreeBSD.org> Date: Thu, 26 Jul 2012 01:08:31 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <501056C4.3080806@FreeBSD.org> In-Reply-To: <501056C4.3080806@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:07:20 -0000 On 25.07.2012 23:27, Andriy Gapon wrote: > Preamble. I am trying to understand in detail how things work at GEOM <-> "CAM > disk" boundary. I am looking at scsi_da and ata_da which seem to be twins in > this respect. > > I got an impression that the bioq_disksort calls in the strategy methods and the > related queues are completely useless in the GEOM single-threaded world. > There is only one thread, g_down, that can call a strategy method, the method > enqueues a bio, then calls a schedule function and through xpt_schedule the call > flow continues to a start method which dequeues the bio and off it goes. > I currently can see how a bio queue can accumulate more than one bio. > > What am I missing? :-) > I will be very glad to learn more about this layer if anyone is willing to > educate me. > Thank you in advance. > > P.S. I wrote a very simple to DTrace script to my "theory" experimentally and my > testing with various workloads didn't disprove the theory so far (which doesn't > mean that it is correct, of course). > > The script: > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first == 0/ > { > @["empty"] = count(); > } > > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first != 0/ > { > @["non-empty"] = count(); > } > > It works on all bioq_disksort calls, but I stressing only ada disks at the moment. Different controllers have different command queueing limitations. If you are testing with ahci(4) driver and modern disks, then their 32 command slots per port can be enough for many workloads to enqueue all commands to the hardware and leave queue empty as you've described. But if you take harder workload, or controller/ device without command queueing support, extra requests will be accumulated on that bioq and sorted there. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 21:14:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9711E106564A; Wed, 25 Jul 2012 21:14:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 48FB28FC0A; Wed, 25 Jul 2012 21:14:11 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q6PLE2bT012334; Wed, 25 Jul 2012 15:14:03 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <501056C4.3080806@FreeBSD.org> Date: Wed, 25 Jul 2012 14:14:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> References: <501056C4.3080806@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org X-Mailman-Approved-At: Wed, 25 Jul 2012 22:07:55 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org, freebsd-geom@freebsd.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 21:14:11 -0000 Once the bio is put into the bioq from da_strategy, the CAM scheduler is = called. It may or may not wind up calling dastart right away; if the = simq or devq is frozen, or if the devq has been exhausted, then the io = will be deferred until later and the call stack will unwind back into = g_down. The bioq can therefore accumulate many bio's before being = drained. Draining will usually happen from the camisr, at which point = you can potentially have i/o being initiated from both the camisr and = the g_down threads in parallel. The monolithic locking in CAM right now = prevents this from actually happening, though that's a topic that needs = to be revisited. Scott On Jul 25, 2012, at 1:27 PM, Andriy Gapon wrote: >=20 >=20 > Preamble. I am trying to understand in detail how things work at GEOM = <-> "CAM > disk" boundary. I am looking at scsi_da and ata_da which seem to be = twins in > this respect. >=20 > I got an impression that the bioq_disksort calls in the strategy = methods and the > related queues are completely useless in the GEOM single-threaded = world. > There is only one thread, g_down, that can call a strategy method, the = method > enqueues a bio, then calls a schedule function and through = xpt_schedule the call > flow continues to a start method which dequeues the bio and off it = goes. > I currently can see how a bio queue can accumulate more than one bio. >=20 > What am I missing? :-) > I will be very glad to learn more about this layer if anyone is = willing to > educate me. > Thank you in advance. >=20 > P.S. I wrote a very simple to DTrace script to my "theory" = experimentally and my > testing with various workloads didn't disprove the theory so far = (which doesn't > mean that it is correct, of course). >=20 > The script: > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first =3D=3D 0/ > { > @["empty"] =3D count(); > } >=20 > fbt::bioq_disksort:entry > /args[0]->queue.tqh_first !=3D 0/ > { > @["non-empty"] =3D count(); > } >=20 > It works on all bioq_disksort calls, but I stressing only ada disks at = the moment. > --=20 > Andriy Gapon >=20 From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 22:30:16 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4B92106566B; Wed, 25 Jul 2012 22:30:16 +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 7206D8FC14; Wed, 25 Jul 2012 22:30:15 +0000 (UTC) Received: from porto.starpoint.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 BAA24285; Thu, 26 Jul 2012 01:29:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SuA5d-0009BM-28; Thu, 26 Jul 2012 01:29:57 +0300 Message-ID: <50107362.7050709@FreeBSD.org> Date: Thu, 26 Jul 2012 01:29:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Long References: <501056C4.3080806@FreeBSD.org> <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> In-Reply-To: <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:30:16 -0000 on 26/07/2012 00:14 Scott Long said the following: > Once the bio is put into the bioq from da_strategy, the CAM scheduler is > called. It may or may not wind up calling dastart right away; if the simq or > devq is frozen, or if the devq has been exhausted, then the io will be > deferred until later and the call stack will unwind back into g_down. The > bioq can therefore accumulate many bio's before being drained. Draining will > usually happen from the camisr, at which point you can potentially have i/o > being initiated from both the camisr and the g_down threads in parallel. The Uh-hah. Thank you for the answer. I didn't think of the case of frozen/exhausted queues and also didn't hit in my tests. Now I am starting to understand the logic in xpt_run_dev_allocq. BTW, I think that it would be nice if the GEOM work-processing could re-use the CAM model. That is, try to execute GEOM bio transformations in the original thread as much as possible, defer work to the GEOM thread as the last resort. > monolithic locking in CAM right now prevents this from actually happening, > though that's a topic that needs to be revisited. > On Jul 25, 2012, at 1:27 PM, Andriy Gapon wrote: > >> >> >> Preamble. I am trying to understand in detail how things work at GEOM <-> >> "CAM disk" boundary. I am looking at scsi_da and ata_da which seem to be >> twins in this respect. >> >> I got an impression that the bioq_disksort calls in the strategy methods >> and the related queues are completely useless in the GEOM single-threaded >> world. There is only one thread, g_down, that can call a strategy method, >> the method enqueues a bio, then calls a schedule function and through >> xpt_schedule the call flow continues to a start method which dequeues the >> bio and off it goes. I currently can see how a bio queue can accumulate >> more than one bio. >> >> What am I missing? :-) I will be very glad to learn more about this layer >> if anyone is willing to educate me. Thank you in advance. >> >> P.S. I wrote a very simple to DTrace script to my "theory" experimentally >> and my testing with various workloads didn't disprove the theory so far >> (which doesn't mean that it is correct, of course). >> >> The script: fbt::bioq_disksort:entry /args[0]->queue.tqh_first == 0/ { >> @["empty"] = count(); } >> >> fbt::bioq_disksort:entry /args[0]->queue.tqh_first != 0/ { @["non-empty"] = >> count(); } >> >> It works on all bioq_disksort calls, but I stressing only ada disks at the >> moment. -- Andriy Gapon >> > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 22:36:24 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E520106564A; Wed, 25 Jul 2012 22:36:24 +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 C4C7D8FC15; Wed, 25 Jul 2012 22:36:22 +0000 (UTC) Received: from porto.starpoint.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 BAA24384; Thu, 26 Jul 2012 01:36:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SuABp-0009Bn-9I; Thu, 26 Jul 2012 01:36:21 +0300 Message-ID: <501074E4.4040805@FreeBSD.org> Date: Thu, 26 Jul 2012 01:36:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Motin References: <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org> In-Reply-To: <50106E5F.4030402@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:36:24 -0000 on 26/07/2012 01:08 Alexander Motin said the following: > Different controllers have different command queueing limitations. If you are > testing with ahci(4) driver and modern disks, then their 32 command slots per > port can be enough for many workloads to enqueue all commands to the hardware > and leave queue empty as you've described. But if you take harder workload, or > controller/ device without command queueing support, extra requests will be > accumulated on that bioq and sorted there. Alexander, thank you for the reply. Indeed, using 64 parallel dd processes with bs=512 I was able to 'kick in' the disksort logic. But I am not sure if the disksort algorithm makes much difference in this case given the number of commands that a disk firmware can internally re-order. (Not mentioning that potentially disksort could starve some I/O bound processes in favor of others -- but that's a totally different topic). But then, of course, for the less capable hardware the disksort could still be a significant factor. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 22:40:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E84AE1065670 for ; Wed, 25 Jul 2012 22:40:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54FE48FC15 for ; Wed, 25 Jul 2012 22:40:14 +0000 (UTC) Received: by obbun3 with SMTP id un3so2219239obb.13 for ; Wed, 25 Jul 2012 15:40:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/OhSNf3qOl1/rBiaOGT2DJtTfoLyvlsMZS2FF/XjMgQ=; b=XmyIKsGsltCY+8VXh9piSBR0LiUvmSOW1V8HJYJHFhn4TiEWEtSQ2XJdz3aWAIGpWr 8VyIIsXZtBMH2Ny+PzPGkXDWRClcPVKczkfkLq2Wpmd25CkxwyCpFRvwDjdAtIyZjmcg a2p6sU8Jl2sX3g8Efjkl3+FEPgjxh7zAcTShGkX1alSMdTtQrTH7XgIw+sCRj6i47M0K 6Dy4FaIVD9VzlvcrIrEw9viZcbkSAxfb+6q+c2v2HSWw6rZ4+hZzWlujDBYpS6VpLu+F Mz4kEPYWF0h3fpN04+euYr00x47AAcEQqxO9qg9UD40hHTCkZxVTTmqB3/LdtPVayviR 07Gw== Received: by 10.182.1.72 with SMTP id 8mr38145263obk.61.1343256013961; Wed, 25 Jul 2012 15:40:13 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id hd10sm16944801obc.8.2012.07.25.15.40.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 15:40:13 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50107362.7050709@FreeBSD.org> Date: Wed, 25 Jul 2012 16:40:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF84E40-8B71-4AFD-B457-5B3299BD4F92@bsdimp.com> References: <501056C4.3080806@FreeBSD.org> <23011628-17F1-49A0-A41E-E7A8A8E3EA64@samsco.org> <50107362.7050709@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnDzeM+NCs6C7dzyxuVqSByo1jI3LG3P9pERanG8J4PtBlqAtRBKyHCbTfm8yna58oCTgaM Cc: freebsd-scsi@FreeBSD.org, Scott Long , freebsd-geom@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:40:15 -0000 On Jul 25, 2012, at 4:29 PM, Andriy Gapon wrote: > BTW, I think that it would be nice if the GEOM work-processing could = re-use the > CAM model. > That is, try to execute GEOM bio transformations in the original = thread as much > as possible, defer work to the GEOM thread as the last resort. Lots of people would like to see this. Especially people that want high = iops. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 25 23:47:11 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C1AF106566B; Wed, 25 Jul 2012 23:47:11 +0000 (UTC) (envelope-from prvs=1553f1cdfa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id F0C9C8FC14; Wed, 25 Jul 2012 23:47:09 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 26 Jul 2012 00:46:04 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020941215.msg; Thu, 26 Jul 2012 00:46:04 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1553f1cdfa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <91A8B33A32B546BB82F0A1CFF4D1F4BD@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , "Alexander Motin" References: <501056C4.3080806@FreeBSD.org> <50106E5F.4030402@FreeBSD.org> <501074E4.4040805@FreeBSD.org> Date: Thu, 26 Jul 2012 00:46:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@FreeBSD.org, freebsd-geom@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: geom <-> cam disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 23:47:11 -0000 ----- Original Message ----- From: "Andriy Gapon" > on 26/07/2012 01:08 Alexander Motin said the following: >> Different controllers have different command queueing limitations. If you are >> testing with ahci(4) driver and modern disks, then their 32 command slots per >> port can be enough for many workloads to enqueue all commands to the hardware >> and leave queue empty as you've described. But if you take harder workload, or >> controller/ device without command queueing support, extra requests will be >> accumulated on that bioq and sorted there. > > Alexander, > > thank you for the reply. > Indeed, using 64 parallel dd processes with bs=512 I was able to 'kick in' the > disksort logic. But I am not sure if the disksort algorithm makes much > difference in this case given the number of commands that a disk firmware can > internally re-order. (Not mentioning that potentially disksort could starve > some I/O bound processes in favor of others -- but that's a totally different > topic). > > But then, of course, for the less capable hardware the disksort could still be a > significant factor. The sort is actually important for delete requests too as this can allow the delete processing code to operate more effectively which can result in significant performance increases if this then allows request combining. For example Alexander is currently reviewing some changes I've written to the delete processing which include an optimisation that increases SSD delete performance from ~630MB/s to 1.3GB/s on 3rd gen sandforce controllers. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 26 01:56:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9291065672; Thu, 26 Jul 2012 01:56:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 57C788FC0C; Thu, 26 Jul 2012 01:56:58 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so4625402wib.13 for ; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhzF8JyuwbqS8fVrWcEZ31l1TbaG1o7MwkqNM54vAYM=; b=bx/ck+YCoSzdZdM40y+pWEKQ+WCKp0njuPN5rcCf940wWcnAfuxQsYK4dbLGhQ5xWu qF5RF21mDgPf2AxbqXhe2fmtr59HD/NXTcZCpZtHmfwpKPS+j+4mZF+CoMg9kABZyTmd Y+Mggi1G+c/h13gYJI6GTB5GY1f8V40rbwW50v0SvleJp0rkaTJ2XGAACbfPU7s9R3Vx 2oZkKDhWynfTzCQrtfOpn0uroPUtUC7yIM3in0YsH1kDL50eZuqaIVIJsoOOFLO07NMX XqFvdUTMijdxazR5/7PHdoVjxCkRvKppUUFKlX6hx27JGDXj/Gdnt6pL1NMt5t5siAwe FxwA== MIME-Version: 1.0 Received: by 10.180.84.104 with SMTP id x8mr9201281wiy.20.1343267817120; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) Received: by 10.216.227.70 with HTTP; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) In-Reply-To: <500FD7B9.4070804@freebsd.org> References: <500FD7B9.4070804@freebsd.org> Date: Wed, 25 Jul 2012 21:56:57 -0400 Message-ID: From: Arnaud Lacombe To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , FreeBSD Hackers Subject: Re: Generic queue's KPI to manipulate mbuf's queue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:56:59 -0000 Hi, On Wed, Jul 25, 2012 at 7:25 AM, Andre Oppermann wrote: > On 24.07.2012 20:18, Arnaud Lacombe wrote: >> >> Hi, >> >> AFAIK, there is no proper KPI for managing mbuf queue. All users have > Before we can talk about an mbuf queue you have to define what you > want to "queue". Is it packets or an mbuf chain which doesn't have > clear delimiters (as with tcp for example)? Depending on that the > requirements and solutions may be vastly different. > I was thinking about queues as in "general use-case of m_nextpkt", that would be dummynet queuing, QoS, various reassembly queues, socket buffer, etc... >> to re-implements the queue logic from scratch, which is less than >> optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do >> not need a new list implementation". There has been a few attempt of >> providing a queue API, namely , but that is >> nothing more than an ad-hoc solution to something which _has_to_be_ >> generic. For the sake of adding more mess in the tree, this >> implementation has been duplicated in ... > > Duplication is always a sign for the need of a generic approach/KPI. > > >> Now, I understand, or at least merely witness without power, the >> reluctance of kernel hackers to have 'struct mbuf` evolves, especially >> wrt. their desire to keep binary compatibility of KPI[0]. Now, none of >> the current ad-hoc API matched my needs, and I really did NOT want to >> re-implement a new list implementation for missing basic operation, >> such as deleting an element of the list, so I came with the attached >> patch. The main idea is to be able to use already existing code from >> for mbuf queuing management. It is not the best which >> can be done. I am not a huge fan of keeping `m_nextpkt' and >> introducing a `m_nextelm', I would have preferred to use TAILQs, and I >> do not like the dwelling in SLIST internal implementation details. >> However, this change is relatively lightweight, and change neither ABI >> or API. > > IMO your change is a rather elegant way of introducing the LIST macros > to the mbuf nextpkt field. I do like it and don't object to it providing > you sufficiently answer the question in the first paragraph. > actually, I made a mistake selecting SLISTs, it should really be an STAILQ. It has the same advantage wrt. ABI, and most usage made of `m_nextpkt' follows a tail queue logic. The only advantage of TAILQ would be reverse traversal, and time constant removal of inner elements. - Arnaud > -- > Andre > >> Any comment appreciated. >> >> - Arnaud >> >> [0]: taking care of having a stable kernel ABI and *not* a stable >> userland ABI is beyond my understanding, but this is not the subject >> of this mail. >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 27 08:11:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B6F31065670 for ; Fri, 27 Jul 2012 08:11:11 +0000 (UTC) (envelope-from dediupit@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E914E8FC08 for ; Fri, 27 Jul 2012 08:11:10 +0000 (UTC) Received: by obbun3 with SMTP id un3so5068333obb.13 for ; Fri, 27 Jul 2012 01:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w4/8+Yp/xrVFMZNiRfnDPrh9gLoyFRJlb1bqJT15Ckw=; b=Ah5xmAi523uwTlwHTmeSL3nVa836PnXUQurDrRWZd/h6sYkelx/jJm6A5TQjmVJrwJ uouPnO+6JbEyCb3kpvVxDoOnucHNqs0hC34HKLgzXTf6xaS6Vyipd9nMx6RG7RTWbKbu 9nv9PYkzjD2JWyDZywg89jo2fYm4xTWtYXqy5zkz9fmj2IIxTXBli9Tvly4HD4XmGBdQ l2YIl8TkZ6hle6fvwFpZ4ki1iOPwaAcB8zmMtb/ziErxHDgIbDmlAJsO9tTDByUUe1+i q4I0u1uMvWzGJ+fC19n/eg95TYclamnDeZWMZnNFgnskVitXPwRvmYiI29fYzSM0njfD b7jA== MIME-Version: 1.0 Received: by 10.182.74.66 with SMTP id r2mr2397480obv.29.1343376670630; Fri, 27 Jul 2012 01:11:10 -0700 (PDT) Received: by 10.60.9.70 with HTTP; Fri, 27 Jul 2012 01:11:10 -0700 (PDT) Date: Fri, 27 Jul 2012 15:11:10 +0700 Message-ID: From: Dedi Upit To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (no subject) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 08:11:11 -0000 helllo...i'am dedi From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 27 13:53:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 526FF106564A for ; Fri, 27 Jul 2012 13:53:09 +0000 (UTC) (envelope-from prvs=1555b974d3=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C36688FC17 for ; Fri, 27 Jul 2012 13:53:08 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 27 Jul 2012 14:52:19 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020962570.msg for ; Fri, 27 Jul 2012 14:52:18 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1555b974d3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Caza, Aaron" , References: Date: Fri, 27 Jul 2012 14:52:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Subject: Re: AHCI Timeouts on SATA III with Intel 520 SSDs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:53:09 -0000 Did you get anywhere with this? Seeing a similar thing on some new Patsburg based machines with KINGSTON SSD's on 8.3-RELEASE. Regards Steve ----- Original Message ----- From: "Caza, Aaron" To: Sent: Monday, February 13, 2012 9:58 PM Subject: AHCI Timeouts on SATA III with Intel 520 SSDs I've got a couple of Intel 520 SSDs that I'm running on an Intel Sandy-bridge based system(Core i5-2500K H67 chipset). Unfortunately, the drives experience AHCI Timeouts when connected to the SATA III ports. If, however, I connect the drives to the SATA-II ports on the same system the drives do not timeout. NCQ is enabled. Below is the complete dmesg showing the issue. For my testing, I'm just using a FreeBSD 9.0 Release (amd64) generic kernel using 'dd if=/dev/ada0 of=/dev/null bs=1m' to exhibit the behavior. The drives, ofcourse, are brand new and again if I run them off the SATA-II ports instead of the SATA-III ports the problem goes away but then so does the performance. Suggestions? gpart show ada0: => 34 234441581 ada0 GPT (111G) 34 128 1 freebsd-boot (64k) 162 232783872 2 freebsd-ufs (111G) 232784034 1657581 - free - (809M) camcontrol identify ada0: pass0: ATA-9 SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model INTEL SSDSC2CW120A3 firmware revision 400i serial number WWN 5001517bb27d76f7 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 234441648 sectors LBA48 supported 234441648 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff Features2=0x179ae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16459304960 (15696 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xfe000000-0xfe3fffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xfe603000-0xfe6033ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci3: on pcib3 xhci0: mem 0xfe500000-0xfe507fff irq 17 at device 0.0 on pci3 xhci0: 32 byte context size. usbus1 on xhci0 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 xhci1: mem 0xfe400000-0xfe407fff irq 18 at device 0.0 on pci4 xhci1: 32 byte context size. usbus2 on xhci1 pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 re0: port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 19 at device 0.0 on pci5 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 80:ee:73:14:6d:b1 pcib6: irq 17 at device 28.4 on pci0 pci6: on pcib6 ehci1: mem 0xfe602000-0xfe6023ff irq 23 at device 29.0 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xfe601000-0xfe6017ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 orm0: at iomem 0xc0000-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 5.0Gbps Super Speed USB v3.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b21> at usbus1 uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: <0x1b21> at usbus2 uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 12861691 Hz quality 1000 Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub1: 4 ports with 4 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 usbus0 ugen0.2: at usbus0 uhub4: on usbus0 ugen3.2: at usbus3 uhub5: on usbus3 Root mount waiting for: usbus3 usbus0 uhub4: 6 ports with 6 removable, self powered uhub5: 8 ports with 8 removable, self powered ugen3.3: at usbus3 ukbd0: on usbus3 kbd0 at ukbd0 Trying to mount root from ufs:/dev/ada0p2 [rw]... ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 06000000 ss 07000000 rs 07000000 tfd 40 serr 00880000 cmd 0000d817 ahcich0: Timeout on slot 21 port 0 ahcich0: is 00000000 cs 00c00000 ss 00e00000 rs 00e00000 tfd 40 serr 00880000 cmd 0000d517 ahcich0: Timeout on slot 28 port 0 ahcich0: is 00000000 cs e000000f ss f000000f rs f000000f tfd 40 serr 00880000 cmd 0000dc17 ahcich0: Timeout on slot 25 port 0 ahcich0: is 00000000 cs 00000000 ss 02000000 rs 02000000 tfd 40 serr 00880000 cmd 0000d917 ahcich0: Timeout on slot 16 port 0 ahcich0: is 00000000 cs 00000000 ss 00010000 rs 00010000 tfd 40 serr 00880000 cmd 0000d017 ahcich0: Timeout on slot 19 port 0 ahcich0: is 00000000 cs 00000000 ss 00080000 rs 00080000 tfd 40 serr 00880000 cmd 0000d317 ahcich0: Timeout on slot 22 port 0 ahcich0: is 00000000 cs 01800000 ss 01c00000 rs 01c00000 tfd 40 serr 00880000 cmd 0000d617 ahcich0: Timeout on slot 9 port 0 ahcich0: is 00000000 cs 0000fc00 ss 0000fe00 rs 0000fe00 tfd 40 serr 00880000 cmd 0000c917 ahcich0: Timeout on slot 17 port 0 ahcich0: is 00000000 cs 00000000 ss 00020000 rs 00020000 tfd 40 serr 00880000 cmd 0000d117 ahcich0: Timeout on slot 1 port 0 ahcich0: is 00000000 cs 00000000 ss 00000002 rs 00000002 tfd 40 serr 00880000 cmd 0000c117 ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 01000000 ss 01000000 rs 01000000 tfd c0 serr 00880000 cmd 0000d817 ahcich0: Timeout on slot 5 port 0 ahcich0: is 00000000 cs 00000000 ss 00000020 rs 00000020 tfd 40 serr 00880000 cmd 0000c517 ahcich0: Timeout on slot 8 port 0 ahcich0: is 00000000 cs 00000000 ss 00000100 rs 00000100 tfd 40 serr 00880000 cmd 0000c817 ahcich0: Timeout on slot 9 port 0 ahcich0: is 00000000 cs 00000000 ss 00000200 rs 00000200 tfd 40 serr 00880000 cmd 0000c917 ahcich0: Timeout on slot 12 port 0 ahcich0: is 00000000 cs 00000000 ss 00001000 rs 00001000 tfd 40 serr 00880000 cmd 0000cc17 ahcich0: Timeout on slot 26 port 0 ahcich0: is 00000000 cs 00000000 ss 04000000 rs 04000000 tfd 40 serr 00880000 cmd 0000da17 ahcich0: Timeout on slot 27 port 0 ahcich0: is 00000000 cs 00000000 ss 08000000 rs 08000000 tfd 40 serr 00880000 cmd 0000db17 ahcich0: Timeout on slot 28 port 0 ahcich0: is 00000000 cs 00000000 ss 10000000 rs 10000000 tfd 40 serr 00880000 cmd 0000dc17 ahcich0: Timeout on slot 4 port 0 ahcich0: is 00000000 cs 00000000 ss 00000010 rs 00000010 tfd 40 serr 00880000 cmd 0000c417 This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. PLEASE NOTE that all incoming e-mails sent to Weatherford e-mail accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional e-mails (spam). This process could result in deletion of a legitimate e-mail before it is read by its intended recipient at our organization. Moreover, based on the scanning results, the full text of e-mails and attachments may be made available to Weatherford security and other personnel for review and appropriate action. If you have any concerns about this process, please contact us at dataprivacy@weatherford.com. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 27 16:37:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F301106566B for ; Fri, 27 Jul 2012 16:37:38 +0000 (UTC) (envelope-from Aaron.Caza@ca.weatherford.com) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFC48FC0A for ; Fri, 27 Jul 2012 16:37:37 +0000 (UTC) Received: from mail121-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 16:07:18 +0000 Received: from mail121-am1 (localhost [127.0.0.1]) by mail121-am1-R.bigfish.com (Postfix) with ESMTP id 6DFCD1E0566; Fri, 27 Jul 2012 16:07:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.126; KIP:(null); UIP:(null); IPV:NLI; H:owa.weatherford.com; RD:none; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zz9371Ifb6I542M55dIzz1202hzz8275bh8275dhz2fh2a8h668h839h8e2h8e3h944hd25hf0ah107ahbe9i) Received-SPF: pass (mail121-am1: domain of ca.weatherford.com designates 70.37.183.126 as permitted sender) client-ip=70.37.183.126; envelope-from=Aaron.Caza@ca.weatherford.com; helo=owa.weatherford.com ; therford.com ; Received: from mail121-am1 (localhost.localdomain [127.0.0.1]) by mail121-am1 (MessageSwitch) id 1343405234235316_5126; Fri, 27 Jul 2012 16:07:14 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.231]) by mail121-am1.bigfish.com (Postfix) with ESMTP id DBCDA40045; Fri, 27 Jul 2012 16:07:13 +0000 (UTC) Received: from owa.weatherford.com (70.37.183.126) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 16:07:10 +0000 Received: from 032-SN2MPN1-052.032d.mgd.msft.net ([fe80::3480:ae86:823c:83ef]) by 032-SN1MMR1-009.032d.mgd.msft.net ([2002:aa85:c61f::aa85:c61f]) with mapi id 14.02.0298.005; Fri, 27 Jul 2012 11:07:09 -0500 From: "Caza, Aaron" To: Steven Hartland , "freebsd-hackers@freebsd.org" Thread-Topic: AHCI Timeouts on SATA III with Intel 520 SSDs Thread-Index: AczqkBE+uXo5uTWmSlGQ0gy+bH0uVQAAdXeQIFtRAvIAA+We0A== Date: Fri, 27 Jul 2012 16:07:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.91.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ca.weatherford.com Cc: Subject: RE: AHCI Timeouts on SATA III with Intel 520 SSDs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 16:37:38 -0000 Yes. In my case, the problem turned out to be a marginal SATA-III port on = the motherboard which was determined after swapping SSDs, SATA cables, etce= tera to finally pin down the problem. When trouble-shooting this issue, I = recall googling a particular missive by Alexander Motion in which he indica= tes these problems are potentially due to any number of hardware-related re= asons hence the exhaustive search for the culprit which, as he suggested, d= id indeed turn out to be the hardware. It's actually rather interesting = how borderline hardware can be - the port in question could handle an Intel= 510 SSD running at full SATA-III speed but an Intel 520 pushed it over the= brink. -----Original Message----- From: Steven Hartland [mailto:killing@multiplay.co.uk] Sent: Friday, July 27, 2012 7:52 AM To: Caza, Aaron; freebsd-hackers@freebsd.org Subject: Re: AHCI Timeouts on SATA III with Intel 520 SSDs Did you get anywhere with this? Seeing a similar thing on some new Patsburg based machines with KINGSTON SS= D's on 8.3-RELEASE. Regards Steve ----- Original Message ----- From: "Caza, Aaron" To: Sent: Monday, February 13, 2012 9:58 PM Subject: AHCI Timeouts on SATA III with Intel 520 SSDs I've got a couple of Intel 520 SSDs that I'm running on an Intel Sandy-brid= ge based system(Core i5-2500K H67 chipset). Unfortunately, the drives experience AHCI Timeouts when connected to the SA= TA III ports. If, however, I connect the drives to the SATA-II ports on the same system the drives do not timeout. NCQ is enabled= . Below is the complete dmesg showing the issue. For my testing, I'm just using a FreeBSD 9.0 Release (amd64) generic kernel usi= ng 'dd if=3D/dev/ada0 of=3D/dev/null bs=3D1m' to exhibit the behavior. The drives, ofcourse, are brand new and again if I run them off = the SATA-II ports instead of the SATA-III ports the problem goes away but then so does the performance. Suggestions? gpart show ada0: =3D> 34 234441581 ada0 GPT (111G) 34 128 1 freebsd-boot (64k) 162 232783872 2 freebsd-ufs (111G) 232784034 1657581 - free - (809M) camcontrol identify ada0: pass0: ATA-9 SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model INTEL SSDSC2CW120A3 firmware revision 400i serial number WWN 5001517bb27d76f7 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 234441648 sectors LBA48 supported 234441648 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a St= epping =3D 7 Features=3D0xbfebfbff Features2=3D0x179ae3bf AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16459304960 (15696 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xfe000000-0xfe3ff= fff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xfe603000-0xfe6033ff irq 16= at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci3: on pcib3 xhci0: mem 0xfe500000-0xfe507fff irq 17= at device 0.0 on pci3 xhci0: 32 byte context size. usbus1 on xhci0 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 xhci1: mem 0xfe400000-0xfe407fff irq 18= at device 0.0 on pci4 xhci1: 32 byte context size. usbus2 on xhci1 pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 re0: port 0xe000-0x= e0ff mem 0xd0004000-0xd0004fff,0xd0000000-0xd0003fff irq 19 at device 0.0 on pci5 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow= -master, auto, auto-flow re0: Ethernet address: 80:ee:73:14:6d:b1 pcib6: irq 17 at device 28.4 on pci0 pci6: on pcib6 ehci1: mem 0xfe602000-0xfe6023ff irq 23= at device 29.0 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf0b0-0xf0b7,0xf0a0-= 0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xfe601000-0xfe6017ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 orm0: at iomem 0xc0000-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 5.0Gbps Super Speed USB v3.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b21> at usbus1 uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: <0x1b21> at usbus2 uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-9 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 12861691 Hz quality 1000 Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub1: 4 ports with 4 removable, self powered uhub2: 4 ports with 4 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 usbus0 ugen0.2: at usbus0 uhub4: on = usbus0 ugen3.2: at usbus3 uhub5: on = usbus3 Root mount waiting for: usbus3 usbus0 uhub4: 6 ports with 6 removable, self powered uhub5: 8 ports with 8 removable, self powered ugen3.3: at usbus3 ukbd0: on usbus3 kbd0 at ukbd0 Trying to mount root from ufs:/dev/ada0p2 [rw]... ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 06000000 ss 07000000 rs 07000000 tfd 40 serr 008800= 00 cmd 0000d817 ahcich0: Timeout on slot 21 port 0 ahcich0: is 00000000 cs 00c00000 ss 00e00000 rs 00e00000 tfd 40 serr 008800= 00 cmd 0000d517 ahcich0: Timeout on slot 28 port 0 ahcich0: is 00000000 cs e000000f ss f000000f rs f000000f tfd 40 serr 008800= 00 cmd 0000dc17 ahcich0: Timeout on slot 25 port 0 ahcich0: is 00000000 cs 00000000 ss 02000000 rs 02000000 tfd 40 serr 008800= 00 cmd 0000d917 ahcich0: Timeout on slot 16 port 0 ahcich0: is 00000000 cs 00000000 ss 00010000 rs 00010000 tfd 40 serr 008800= 00 cmd 0000d017 ahcich0: Timeout on slot 19 port 0 ahcich0: is 00000000 cs 00000000 ss 00080000 rs 00080000 tfd 40 serr 008800= 00 cmd 0000d317 ahcich0: Timeout on slot 22 port 0 ahcich0: is 00000000 cs 01800000 ss 01c00000 rs 01c00000 tfd 40 serr 008800= 00 cmd 0000d617 ahcich0: Timeout on slot 9 port 0 ahcich0: is 00000000 cs 0000fc00 ss 0000fe00 rs 0000fe00 tfd 40 serr 008800= 00 cmd 0000c917 ahcich0: Timeout on slot 17 port 0 ahcich0: is 00000000 cs 00000000 ss 00020000 rs 00020000 tfd 40 serr 008800= 00 cmd 0000d117 ahcich0: Timeout on slot 1 port 0 ahcich0: is 00000000 cs 00000000 ss 00000002 rs 00000002 tfd 40 serr 008800= 00 cmd 0000c117 ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 01000000 ss 01000000 rs 01000000 tfd c0 serr 008800= 00 cmd 0000d817 ahcich0: Timeout on slot 5 port 0 ahcich0: is 00000000 cs 00000000 ss 00000020 rs 00000020 tfd 40 serr 008800= 00 cmd 0000c517 ahcich0: Timeout on slot 8 port 0 ahcich0: is 00000000 cs 00000000 ss 00000100 rs 00000100 tfd 40 serr 008800= 00 cmd 0000c817 ahcich0: Timeout on slot 9 port 0 ahcich0: is 00000000 cs 00000000 ss 00000200 rs 00000200 tfd 40 serr 008800= 00 cmd 0000c917 ahcich0: Timeout on slot 12 port 0 ahcich0: is 00000000 cs 00000000 ss 00001000 rs 00001000 tfd 40 serr 008800= 00 cmd 0000cc17 ahcich0: Timeout on slot 26 port 0 ahcich0: is 00000000 cs 00000000 ss 04000000 rs 04000000 tfd 40 serr 008800= 00 cmd 0000da17 ahcich0: Timeout on slot 27 port 0 ahcich0: is 00000000 cs 00000000 ss 08000000 rs 08000000 tfd 40 serr 008800= 00 cmd 0000db17 ahcich0: Timeout on slot 28 port 0 ahcich0: is 00000000 cs 00000000 ss 10000000 rs 10000000 tfd 40 serr 008800= 00 cmd 0000dc17 ahcich0: Timeout on slot 4 port 0 ahcich0: is 00000000 cs 00000000 ss 00000010 rs 00000010 tfd 40 serr 008800= 00 cmd 0000c417 This message may contain confidential and privileged information. If it has= been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the inte= nded recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such una= uthorized use. PLEASE NOTE that all incoming e-mails sent to Weatherford e-mail accounts will be archived and may be scanned by = us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavi= or, and/or eliminate unsolicited promotional e-mails (spam). This process could result in deletion of a legitimate e-mail before= it is read by its intended recipient at our organization. Moreover, based on the scanning results, the full text of e-m= ails and attachments may be made available to Weatherford security and other personnel for review and appropriate action.= If you have any concerns about this process, please contact us at dataprivacy@weatherford.com. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the= person or entity to whom it is addressed. In the event of misdirection, th= e recipient is prohibited from using, copying, printing or otherwise dissem= inating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please t= elephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. This message may contain confidential and privileged information. If it has= been sent to you in error, please reply to advise the sender of the error = and then immediately delete it. If you are not the intended recipient, do n= ot read, copy, disclose or otherwise use this message. The sender disclaims= any liability for such unauthorized use. PLEASE NOTE that all incoming e-m= ails sent to Weatherford e-mail accounts will be archived and may be scanne= d by us and/or by external service providers to detect and prevent threats = to our systems, investigate illegal or inappropriate behavior, and/or elimi= nate unsolicited promotional e-mails (spam). This process could result in d= eletion of a legitimate e-mail before it is read by its intended recipient = at our organization. Moreover, based on the scanning results, the full text= of e-mails and attachments may be made available to Weatherford security a= nd other personnel for review and appropriate action. If you have any conce= rns about this process, please contact us at dataprivacy@weatherford.com. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 27 18:48:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A9581065675 for ; Fri, 27 Jul 2012 18:48:39 +0000 (UTC) (envelope-from prvs=1555b974d3=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id EB2438FC22 for ; Fri, 27 Jul 2012 18:48:38 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 27 Jul 2012 19:47:52 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50020968874.msg for ; Fri, 27 Jul 2012 19:47:51 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1555b974d3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Caza, Aaron" , References: Date: Fri, 27 Jul 2012 19:47:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Subject: Re: AHCI Timeouts on SATA III with Intel 520 SSDs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:48:39 -0000 That's very useful and could well be what we have here. I've got two new machines which run the SSD's fine @ SATA 3 on port 1 but an identical disk on port 2 is having issues. If we switch it down to SATA 2 and all is good. So sounds like the next move is to switch the disks round and see if the problem stays with the disk or the port. Here's hoping its the disk or the cable and not the controller. Regards Steve ----- Original Message ----- From: "Caza, Aaron" To: "Steven Hartland" ; Sent: Friday, July 27, 2012 5:07 PM Subject: RE: AHCI Timeouts on SATA III with Intel 520 SSDs Yes. In my case, the problem turned out to be a marginal SATA-III port on the motherboard which was determined after swapping SSDs, SATA cables, etcetera to finally pin down the problem. When trouble-shooting this issue, I recall googling a particular missive by Alexander Motion in which he indicates these problems are potentially due to any number of hardware-related reasons hence the exhaustive search for the culprit which, as he suggested, did indeed turn out to be the hardware. It's actually rather interesting how borderline hardware can be - the port in question could handle an Intel 510 SSD running at full SATA-III speed but an Intel 520 pushed it over the brink. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 27 22:45:39 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C9DC1065677; Fri, 27 Jul 2012 22:45:39 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3818FC21; Fri, 27 Jul 2012 22:45:38 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6RMiv46059673; Fri, 27 Jul 2012 15:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1343429098; bh=N7XIWWvktNbgEXDlAj33k/me8kMw5+rbK9ZmjOxj2K8=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=nASMT+UqBJFeRtswb4v0rof346goEvmmIuZ53hfGv27VDr/rOwouTiCtFuA/lLfnU jM+lfh2xTiK5iXQEpGPryLu7aqU0Lm89DtCuXBu5TklWNmqfzIOGLaOS2i2g+la6T6 GbqscixyxLfpB4abjGFu3QiDSK1YycVI0Cx2T094= From: Sean Bruno To: Andrew Boyer In-Reply-To: <742407DF-8026-4976-A1F9-A170A62EF87A@averesystems.com> References: <1341863341.6064.11.camel@powernoodle.corp.yahoo.com> <4FFB4770.7050209@FreeBSD.org> <20120710154128.192eb8d6@fabiankeil.de> <1341939155.2573.8.camel@powernoodle.corp.yahoo.com> <20120710205702.5e57168b@fabiankeil.de> <4FFC8479.9080608@FreeBSD.org> <20120711122935.1382e76d@fabiankeil.de> <20120712201741.34573af4@fabiankeil.de> <4FFF2171.1030800@FreeBSD.org> <20120712213615.39640d1f@fabiankeil.de> <4FFF27F0.4000106@FreeBSD.org> <742407DF-8026-4976-A1F9-A170A62EF87A@averesystems.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 27 Jul 2012 15:44:57 -0700 Message-ID: <1343429097.5002.14.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 429097007 Cc: "freebsd-hackers@FreeBSD.org" , Fabian Keil , Andriy Gapon Subject: Re: dtraceall.ko with old nfsclient X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 22:45:39 -0000 On Thu, 2012-07-12 at 12:47 -0700, Andrew Boyer wrote: > On Jul 12, 2012, at 3:39 PM, Andriy Gapon wrote: > > > on 12/07/2012 22:36 Fabian Keil said the following: > >> Andriy Gapon wrote: > >> > >>> on 12/07/2012 21:17 Fabian Keil said the following: > >>>> Benjamin Kaduk wrote: > >>>> > >>>>> On Wed, 11 Jul 2012, Fabian Keil wrote: > >>>>> > >>>>>> I'm using the following modification of Sean's patch: > >>>> > >>>> This way it seems to work as expected: > >>>> > >>>> diff --git a/sys/modules/dtrace/dtraceall/Makefile > >>>> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644 > >>>> --- a/sys/modules/dtrace/dtraceall/Makefile +++ > >>>> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: > >>>> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs > >>>> Exp $ > >>>> > >>>> KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h > >>>> +SRCS= dtraceall.c opt_compat.h opt_nfs.h > >>>> > >>>> CFLAGS+= -I${.CURDIR}/../../.. > >>>> > >>> > >>> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does > >>> it compile OK with the above change? > >> > >> Depends on your expectations I guess. As neither NFS-related option gets > >> defined, no dependency on either NFS module is registered. The compiler has > >> no complaints, though. > > > > Interesting. Could you repeat after sufficient cleaning up? > > I am not sure where from opt_nfs.h file could come. > > > > Maybe related: check out sys/modules/ipfw/Makefile. It makes its own option headers for INET and INET6. > > -A > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > I've pondered this on an off for a couple of weeks now. I can clearly see that if we want compile time dependencies, that's fine, we can make each nfclient object dependant on the #define. Both are valid cases to have loaded though, so they shouldn't be conditional on each other as in my patches. If one does this however, the module makefile needs to be adjusted like the ipfw makefile to create an opt_nfs.h with the NFS client defines, else you will have neither dtrace object available. There isn't a clear way that I can see to compile dtraceall.ko as a module if you are doing so outside of the kernel compile though. The module tree isn't really aware of what you are running, therefore it would have to compile to load both regardless. Which, if your kernel doesn't support one or both nfs objects, will cause a kldload failure. I'm not real clear how to unwind this situation. Sean From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 28 14:11:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC932106566B for ; Sat, 28 Jul 2012 14:11:10 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by mx1.freebsd.org (Postfix) with SMTP id 80ED18FC12 for ; Sat, 28 Jul 2012 14:11:10 +0000 (UTC) Received: from [98.139.91.63] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2012 14:11:04 -0000 Received: from [98.139.91.16] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2012 14:11:04 -0000 Received: from [127.0.0.1] by omp1016.mail.sp2.yahoo.com with NNFMP; 28 Jul 2012 14:11:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 464342.27463.bm@omp1016.mail.sp2.yahoo.com Received: (qmail 10906 invoked by uid 60001); 28 Jul 2012 14:11:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1343484663; bh=ekBYrmyu9f0BYalLqNy3TIzvowCcHW2+3YKnJ3r5SLA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C0hjzBmEPFi83VFbsA7Ig61/FfM/ZShv3pCLnMIXltCxUeVXXN+fCZXZjA1+gWbSbOsXpMr4IsEssYNBwwXqa308nUN/Kz1xvHBqY+8K/i7QBp16NJ1n4GxgJw3T+Hi125zBZqXx1MGNzh16iUHZQRZjox1k2SNmfx7q6R8Zk4E= X-YMail-OSG: Bf_o7jQVM1mVaWw2zFv405ymvYAXiQefDWLEbvHaWWImJyP cic_pehH1Cs2leZ8KQmfZPBKiYiTMQWrTbpuk3eo3s__PM5g.t5FXo6DdKZL K6jZr7XcLc0Zmnnxq8LORhKonFGRoA_xUQe2ZMRZkUSUM4NAiWqJ6RbnBO36 ZZtAzxtW70iGHAbAN13xo3wFDH3vf1FRZgU..5p1LySkxfzAQqJW_AZFkSXB p.z8z9vCW_5tdDRTqWqLHf3RwU2cwnIlKK0oBtlaNChCCM2GNeFYv3a4x_S2 2bhQvWOfzrN1SxHX2IBr6SwX.HL799mjZ6da3sGwvDXG62F01VWu4jTU9ATx DtjudBwOBb0pfXxtvhrcg7_OX9O2sWPujhfzDwRXQwpIzmDAQnqZZIYrFlvb iTGR37w6JaWOAAOgwJg6PESO9TM7kRu9CRVHRlKEl.DggaV1rV2da6KQNTc. fKxpK6qwrmeJaNhj0QWD90rYIx2INZunkFGQLxHrldo7qpfqxVO.nJ.J7TVD toZyf7fI9r_QyQEPK0epFbByDAu7QhGBIrvM20UftoY5xb69Xq0hyW0ztFUD r Received: from [200.118.157.7] by web113513.mail.gq1.yahoo.com via HTTP; Sat, 28 Jul 2012 07:11:02 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1343484662.97324.YahooMailNeo@web113513.mail.gq1.yahoo.com> Date: Sat, 28 Jul 2012 07:11:02 -0700 (PDT) From: Pedro Giffuni To: Rayson Ho MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" Subject: Re: libdwarf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pedro Giffuni List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 14:11:10 -0000 Hello guys;=0A=0AWe are not using the dwarfstd library because it is copyle= ft and=A0=0ASGI=A0basically seems to have abandoned it for good.=0A=0AThe E= lftoolchain guys have taken over the development started=A0=0Aby John Birre= ll and are the official maintainers of the BSD version:=0A=0A=0Ahttp://sour= ceforge.net/apps/trac/elftoolchain/=A0=0A=0A=0A=0Acheers,=0A=0APedro.