From owner-freebsd-performance@FreeBSD.ORG Sun Apr 1 15:41:41 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 356651065670; Sun, 1 Apr 2012 15:41:41 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DDD238FC08; Sun, 1 Apr 2012 15:41:40 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SEMuM-0006VC-9d>; Sun, 01 Apr 2012 17:41:34 +0200 Received: from e178035008.adsl.alicedsl.de ([85.178.35.8] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SEMuM-000479-4J>; Sun, 01 Apr 2012 17:41:34 +0200 Message-ID: <4F787727.1040209@zedat.fu-berlin.de> Date: Sun, 01 Apr 2012 17:41:27 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Ivan Klymenko References: <4EE938FB.7010107@zedat.fu-berlin.de> <20120329212322.20605a7b@nonamehost.> In-Reply-To: <20120329212322.20605a7b@nonamehost.> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1AC2394BE9801AFAB81D58CA" X-Originating-IP: 85.178.35.8 Cc: freebsd-performance@freebsd.org, Current FreeBSD Subject: Re: NEWS: NVIDIA Open-Sources Its CUDA Compiler X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 15:41:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1AC2394BE9801AFAB81D58CA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 03/29/12 20:23, schrieb Ivan Klymenko: > =D0=92 Thu, 15 Dec 2011 01:02:03 +0100 > "O. Hartmann" =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: >=20 >> Just read this on >> >> phoronix.com >> >> Is this finally a chance to get GPGPU on FreeBSD natively supported? >> >> nVidia has a binary driver, supporting well their higher end graphics >> cards on FreeBSD 64bit natively. >> >> I do not understand much about the compiler itself, it's "nvcc" as far= >> as I know, and it is also doing well OpenCL (with some serious bugs we= >> revealed). >> >> What would be needed to bring FreeBSd finally back to the HPC scenario= >> with being capable of dealing natively with GPGPU stuff on nVidia >> graphics cards? There are libraries installed by the driver or the >> SDK. With a OpenSource compiler it should also be possible for nVidia,= >> assumed the compiler works with freeBSD natively, to provide OpenCL >> stuff as well as CUDA stuff. >> Please correct me and destroy me "dreams" having FreeBSD in my lab >> working on GPUs ... >> >> The decission sounds like some pitfall in a contract. Is nVidia >> dropping CUDA in favour of OpenCL or is the CUDA compiler only a tiny >> piece of the whole thing that could be easily considered open source >> without changing the "great restricted Linux-only" picture? >> >> Maybe LLVM, now part of FreeBSD's backbone, is capable of taking >> advantage of the opening of the CUDA compiler so we will see a >> combination of CLANG/OpenCL/CUDA soon on FreeBSD introduced by LLVM? >> >> Well, well, this is awesome ... ;-) >> >> Oliver >> >=20 > Perhaps it will interest yous http://runtime.bordeaux.inria.fr/StarPU/ > Just tried it - excellent build from source code in FreeBSD CURRENT. Thanks. This seems promising. Regards, Oliver --------------enig1AC2394BE9801AFAB81D58CA 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 (FreeBSD) iQEcBAEBAgAGBQJPeHctAAoJEOgBcD7A/5N8WlEH/0G729hbG29fhzJAGCL5Vdln T5yb3H3vTwZiUmY7F1MnGd1y994Lz+faK66QDG33VidghKC6nU2tPYKgCK9LJ2jT 5vT7pVi3H9K/l6hRq2DeVYonYu3SMu3GU2vAsJxbvAOeAOAmGalZzXNYvkQ8VLIX H8VWIGP6T6VfAQSCZo+v5T7TbPrk1J1mG5AVVAIcMl3HhqwDnHp1+PQ+K4zH8L2w OMOVoVHQuGBzQWpj1PPTa1+PdlnXWKM436yozuOB9a8HgilakPKrtdi94J7Ffgrb gK2R+f7cLbvNWpaCvHeuYctZxUjYPr1IvOJPTbo8GbkzK9dqoJJV+WdJcNd0MdQ= =8VRF -----END PGP SIGNATURE----- --------------enig1AC2394BE9801AFAB81D58CA-- From owner-freebsd-performance@FreeBSD.ORG Thu Apr 5 18:03:02 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C12131065670; Thu, 5 Apr 2012 18:03:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5C08FC0C; Thu, 5 Apr 2012 18:03:02 +0000 (UTC) Received: by yenl9 with SMTP id l9so1070535yen.13 for ; Thu, 05 Apr 2012 11:03:01 -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=dftF+35b3mfWAccN/RmYGaRA6o6qu/X7WfSrtlYq44Y=; b=Pn3RCKDKatzwDYH6XKkiV1cicmfqOQdhNN4CnHzyzmZMZz8oSKXu9aq85SWEE9kf8k k/FOmNfvrEGKu8XTaQ1vof1WdweCH0HvwT4G55uTzY34bFP7p3IgtStZB5VTjZ1sfUts 0dtrznCji8lPpn89Rsskgt5exl4sSCjH8mdhcosNafrW0J/55puBwur9nuj2C0yET6e+ +dzmg32vElU4tDwgAffYYiESy5Gu+7OW1VoxNIyyU0vDdrZL+BV4r7pl4A8b5jNSAdiw 4KRzmMCYxmbmsb2/eaDdj07z6NHF58rz6rSlUCYOjjzQyVJad1DTOuDy8V/zm7JcCrmp fr9g== MIME-Version: 1.0 Received: by 10.236.125.168 with SMTP id z28mr3212653yhh.120.1333648981760; Thu, 05 Apr 2012 11:03:01 -0700 (PDT) Received: by 10.220.185.138 with HTTP; Thu, 5 Apr 2012 11:03:01 -0700 (PDT) Date: Thu, 5 Apr 2012 14:03:01 -0400 Message-ID: From: Arnaud Lacombe To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 05 Apr 2012 18:21:31 +0000 Cc: FreeBSD Current Subject: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:03:02 -0000 Hi folks, Over the past months, I ran on a couple of unused box the `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking down various kind of regression/improvement. `hackbench' is a scheduler + IPC test (socket xor pipe). It creates producers/consumers groups and let a variable quantity of small messages flow happily. Producers and consumers are either processes xor threads. Tested platforms were - Atom D510, Intel, (incomplete) - Core 2 Quad Q9560, Intel - Soekris net5501, AMD (incomplete) - Xeon E5645, Intel (incomplete) - Xeon E5620 (dual package), Intel - Xeon E5-1650 (pending completion) - Vortex86, DMP Tested kernel were: - FreeBSD 7.4-RELEASE - FreeBSD 8.2-RELEASE - FreeBSD 9.0-RC3 and FreeBSD 9.0-RELEASE - FreeBSD 10-CURRENT as of r231573 on the following architecture: - amd64 (if supported, incomplete) - i386 1) DISCLAMER Let me start by pointing out something important: [I] "I am _not_ interested in testing released version FOO with feature BAR enabled, if enabling BAR require a kernel rebuild." All tests for release kernels were made for the kernel shipped officially, it is the developers responsability to decide whether or not enable a feature by default, not mine. If option BAR gives a 20% performance improvement, enable it, don't complain the test to be 20% slower. [II] "I am _not_ interested in altering any hints, tunables or sysctl, unless they prevent the execution of the test." The exception added to the above rule is due to limitation introduced by `kern.threads.max_threads_per_proc' and `kern.ipc.maxpipekva'. Those were respectively set to 8192 and between 16M/64M. note: rule [I] is alleviated for -CURRENT kernels, which were built with the same alteration made to GENERIC during the CURRENT->RELEASE transition (ie. WITNESS and a couple of other option disabled). 2) Tests description `hackbench' has the following tunable: - IPC to use for messaging, either `pipe' or `socket'. - Threading model, either `thread' or `process' - Number of iteration to run - Number of group to create The tests covered all of these adjustments more or less heavily depending on the platform capability. 3) Scripts Test scripts are available in the `master' branch of the git repository at: https://github.com/lacombar/hackbench in the `hackbench/' directory. 4) Results Full results are available in the `runs/*' branches of the GitHub repository. 5) Quick results summary * UP case FreeBSD 9.0 behaves better than FreeBSD 8.2 in process mode, especially with sockets. Results are comparable with thread. 9.0-RC3 shows a 10% hits in thread/socket mode on the LX800, this will need confirmation. Linux is stable and scales linearly in all situation. It is only beaten by FreeBSD 8.2-RELEASE with thread/socket. * MP case These is a pretty bad regression with FreeBSD 9.0 in thread/pipe mode, which scale almost in O(N^2), ending up in way worse performance than FreeBSD 7.4 or 8.2 on the Core 2 Quad. Beside that, it is really difficult to draw a general trends, ie. whether FreeBSD 9.0 behaves better than FreeBSD 8.2, or the other way around. Pretty much all situation arises, FreeBSD 9.0 can beat FreeBSD 8.2 on some workload, behave the same, or be beaten on others. None really scales regularly either. Pretty much every runs shows thresholds where scheduling decision change and/or became erratic. 6) Anticipated question and remarks Q1: "You should truly enable kick-ass feature BAZ in the kernel." R1: "I'm lazy. Do your job as a developer to integrate the feature. If it should be the default, make it the default." Q2: "You should set `kern.vm.whatever' to 42, or enable feature BAZ in the kernel, to get full performance from the Warp engine on Constellation-class starship." R2: "Would you ask Lt. Worf to re-aligh plasma injectors or would ask Lt. Commander La Forge to plan an assault, seriously ?" Q3: "You built the Linux kernel, why can't you rebuild FreeBSD's ?" For a couple of reason: - the Linux kernel does not provide binary release per-se. - the Linux kernel was not the focus of the tests, but merely a comparative of what others-can-do. - I did not tweak the Linux kernel configuration. The kernels configuration tested derived from the `defconfig', with very few amendment[0], mostly about hardware support not enabled by default Q3: "Could you post all the graph ?" R3: I could, but there is really tons of them, so posting a subset of them would be subjective, all the materials is available on the git repository. Q4: "So, how can I get all the graph ?" R4: All you need is git, a posix shell, a couple of utility (find, sort, ...), a recent gnuplot, and a ruby interpreter. Comments and suggestions will be greatly appreciated. - Arnaud [HACKBENCH]: http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c [0]: the exact list is: # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_XZ=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_MODULES is not set CONFIG_X86_BIGSMP=y CONFIG_NR_CPUS=32 CONFIG_PATA_IT8213=y CONFIG_PATA_IT821X=y CONFIG_IGB=y CONFIG_IGBVF=y CONFIG_IXGB=y CONFIG_IXGBE=y CONFIG_IXGBEVF=y # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=y From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 11:48:16 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D788D1065670; Fri, 6 Apr 2012 11:48:16 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3598FC12; Fri, 6 Apr 2012 11:48:16 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SG7eE-0003sb-EL>; Fri, 06 Apr 2012 13:48:10 +0200 Received: from e178024241.adsl.alicedsl.de ([85.178.24.241] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SG7eE-00053l-9F>; Fri, 06 Apr 2012 13:48:10 +0200 Message-ID: <4F7ED7F4.5060509@zedat.fu-berlin.de> Date: Fri, 06 Apr 2012 13:48:04 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Current FreeBSD , freebsd-performance@freebsd.org X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig70781CE9CC0A969DFB7CF99E" X-Originating-IP: 85.178.24.241 Cc: Subject: ECC memory driver in FreeBSD 10? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:48:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig70781CE9CC0A969DFB7CF99E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable I'm looking for a way to force FreeBSD 10 to maintain/watch ECC errors reported by UEFI (or BIOS). Since ECC is said to be essential for server systems both in buisness and science and I do not question this, I was wondering if I can not report ECC errors via a watchdog or UEFI (ACPI?) report to syslog facility on FreeBSD. FreeBSD is supposed to be a server operating system, as far as I know, so I believe there must be something which didn't have revealed itself to me, yet. Thanks in advance, Oliver --------------enig70781CE9CC0A969DFB7CF99E 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 (FreeBSD) iQEcBAEBAgAGBQJPftf5AAoJEOgBcD7A/5N86xMH/2nagjWVsi949+DF9i/oX5KI W/qaJTwJPgBGxmh9r/FRTq9b9caSaZIFOI1chXL2Z3Z5Yg3uHJaJMvYRlm0gdBMu svd5AlkyxCF8JTBw4AOSUucSdv+3IjOf0C7Mfs2JXfMah1J+j27Id4gA4oVAb8Cm ik98UD1n22r4yhl86DorOsoDnUbpiZipkANTVnew2IGviXZJhB74Zv21vvs4mvt5 xvQk+ccPMj9g2IUC8Taeq7xLjNbsM1fay+pB0v4VliUR+ivqMjGarZU+KWtw79wV qE78Tvzt9GvKFN5VE4KGoPYJEtx8YMzERpYeNABfT30sZOoGrljJf7ijWTFaydc= =kHNS -----END PGP SIGNATURE----- --------------enig70781CE9CC0A969DFB7CF99E-- From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 12:33:35 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25065106566B; Fri, 6 Apr 2012 12:33:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4878FC08; Fri, 6 Apr 2012 12:33:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SG8M9-0008BQ-NB>; Fri, 06 Apr 2012 14:33:33 +0200 Received: from e178024241.adsl.alicedsl.de ([85.178.24.241] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SG8M9-00072d-Ge>; Fri, 06 Apr 2012 14:33:33 +0200 Message-ID: <4F7EE297.2000402@zedat.fu-berlin.de> Date: Fri, 06 Apr 2012 14:33:27 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0453718867B7A11D2983DCD6" X-Originating-IP: 85.178.24.241 Cc: freebsd-performance@freebsd.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:33:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0453718867B7A11D2983DCD6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/05/12 20:03, schrieb Arnaud Lacombe: > Hi folks, >=20 > Over the past months, I ran on a couple of unused box the > `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking > down various kind of regression/improvement. `hackbench' is a > scheduler + IPC test (socket xor pipe). It creates producers/consumers > groups and let a variable quantity of small messages flow happily. > Producers and consumers are either processes xor threads. >=20 > Tested platforms were > - Atom D510, Intel, (incomplete) > - Core 2 Quad Q9560, Intel > - Soekris net5501, AMD (incomplete) > - Xeon E5645, Intel (incomplete) > - Xeon E5620 (dual package), Intel > - Xeon E5-1650 (pending completion) > - Vortex86, DMP >=20 > Tested kernel were: > - FreeBSD 7.4-RELEASE > - FreeBSD 8.2-RELEASE > - FreeBSD 9.0-RC3 and FreeBSD 9.0-RELEASE > - FreeBSD 10-CURRENT as of r231573 >=20 > on the following architecture: > - amd64 (if supported, incomplete) > - i386 >=20 > 1) DISCLAMER >=20 > Let me start by pointing out something important: >=20 > [I] "I am _not_ interested in testing released version FOO with > feature BAR enabled, if enabling BAR require a kernel rebuild." >=20 > All tests for release kernels were made for the kernel shipped > officially, it is the developers responsability to decide whether or > not enable a feature by default, not mine. If option BAR gives a 20% > performance improvement, enable it, don't complain the test to be 20% > slower. >=20 > [II] "I am _not_ interested in altering any hints, tunables or > sysctl, unless they prevent the execution of the test." >=20 > The exception added to the above rule is due to limitation introduced > by `kern.threads.max_threads_per_proc' and `kern.ipc.maxpipekva'. > Those were respectively set to 8192 and between 16M/64M. >=20 > note: rule [I] is alleviated for -CURRENT kernels, which were built > with the same alteration made to GENERIC during the CURRENT->RELEASE > transition (ie. WITNESS and a couple of other option disabled). >=20 >=20 > 2) Tests description >=20 > `hackbench' has the following tunable: > - IPC to use for messaging, either `pipe' or `socket'. > - Threading model, either `thread' or `process' > - Number of iteration to run > - Number of group to create >=20 > The tests covered all of these adjustments more or less heavily > depending on the platform capability. >=20 >=20 > 3) Scripts >=20 > Test scripts are available in the `master' branch of the git repository= at: >=20 > https://github.com/lacombar/hackbench >=20 > in the `hackbench/' directory. >=20 >=20 > 4) Results >=20 > Full results are available in the `runs/*' branches of the GitHub repos= itory. >=20 >=20 > 5) Quick results summary >=20 > * UP case >=20 > FreeBSD 9.0 behaves better than FreeBSD 8.2 in process mode, > especially with sockets. Results are comparable with thread. 9.0-RC3 > shows a 10% hits in thread/socket mode on the LX800, this will need > confirmation. >=20 > Linux is stable and scales linearly in all situation. It is only > beaten by FreeBSD 8.2-RELEASE with thread/socket. >=20 > * MP case >=20 > These is a pretty bad regression with FreeBSD 9.0 in thread/pipe mode, > which scale almost in O(N^2), ending up in way worse performance than > FreeBSD 7.4 or 8.2 on the Core 2 Quad. Beside that, it is really > difficult to draw a general trends, ie. whether FreeBSD 9.0 behaves > better than FreeBSD 8.2, or the other way around. Pretty much all > situation arises, FreeBSD 9.0 can beat FreeBSD 8.2 on some workload, > behave the same, or be beaten on others. None really scales regularly > either. Pretty much every runs shows thresholds where scheduling > decision change and/or became erratic. >=20 > 6) Anticipated question and remarks >=20 > Q1: "You should truly enable kick-ass feature BAZ in the kernel." > R1: "I'm lazy. Do your job as a developer to integrate the feature. If > it should be the default, make it the default." >=20 > Q2: "You should set `kern.vm.whatever' to 42, or enable feature BAZ in > the kernel, to get full performance from the Warp engine on > Constellation-class starship." > R2: "Would you ask Lt. Worf to re-aligh plasma injectors or would ask > Lt. Commander La Forge to plan an assault, seriously ?" >=20 > Q3: "You built the Linux kernel, why can't you rebuild FreeBSD's ?" > For a couple of reason: >=20 > - the Linux kernel does not provide binary release per-se. >=20 > - the Linux kernel was not the focus of the tests, but merely a > comparative of what others-can-do. >=20 > - I did not tweak the Linux kernel configuration. The kernels > configuration tested derived from the `defconfig', with very few > amendment[0], mostly about hardware support not enabled by default >=20 > Q3: "Could you post all the graph ?" > R3: I could, but there is really tons of them, so posting a subset of > them would be subjective, all the materials is available on the git > repository. >=20 > Q4: "So, how can I get all the graph ?" > R4: All you need is git, a posix shell, a couple of utility (find, > sort, ...), a recent gnuplot, and a ruby interpreter. >=20 > Comments and suggestions will be greatly appreciated. >=20 > - Arnaud >=20 > [HACKBENCH]: http://people.redhat.com/mingo/cfs-scheduler/tools/hackben= ch.c >=20 > [0]: the exact list is: >=20 > # CONFIG_KERNEL_GZIP is not set > CONFIG_KERNEL_XZ=3Dy > CONFIG_IKCONFIG=3Dy > CONFIG_IKCONFIG_PROC=3Dy > # CONFIG_MODULES is not set > CONFIG_X86_BIGSMP=3Dy > CONFIG_NR_CPUS=3D32 > CONFIG_PATA_IT8213=3Dy > CONFIG_PATA_IT821X=3Dy > CONFIG_IGB=3Dy > CONFIG_IGBVF=3Dy > CONFIG_IXGB=3Dy > CONFIG_IXGBE=3Dy > CONFIG_IXGBEVF=3Dy > # CONFIG_EXT3_FS is not set > CONFIG_EXT4_FS=3Dy Thank you very much for this work! --------------enig0453718867B7A11D2983DCD6 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 (FreeBSD) iQEcBAEBAgAGBQJPfuKdAAoJEOgBcD7A/5N8qTEIAMduemjFoPHfNvfrEpF5pE0w sdKXOtKm59QEQ58NdJlR3s5AzY147tmhgm8ESSczc7LnFFSze530dlKxcMorSVgC zbQT3CbTtdi5ZlDsroX9qRcKT2gVYGgnFMSnN9HLF55YjveUHr1xgfyzEWLRB0LC oqVQKrnP5md2M+mhVAKI6WdQU8yvs+odNN/Wd5igG/G5IppNneeJDli4+00sm3Np Pyx/SFasxRhQPhHbnpanHU2KZb2g4VvHeMRFV1daJ1e5z/h9qu3SpZcaNMf0BhsS L1T9DGjDso88pE+MSkNdccT8he5Mlatj1ML66m6//D6CicVH1svvnfI0rnDPlig= =z50+ -----END PGP SIGNATURE----- --------------enig0453718867B7A11D2983DCD6-- From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 13:11:12 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D7721065673; Fri, 6 Apr 2012 13:11:12 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 09EF28FC12; Fri, 6 Apr 2012 13:11:12 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id B2299E6475; Fri, 6 Apr 2012 14:11:03 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=references :in-reply-to:mime-version:content-transfer-encoding:content-type :message-id:cc:from:subject:date:to; s=mail; bh=E79OtnrIbh7ecTgw ZZqquqpro18=; b=ggElfuWaCRhVwqf/NeGHaZ0naMzQZi2PUgnMYXB7mwV9sbiQ jsK6Cf8qosiAgEaSZjjLTVtToPbB63FBOm1QEelcw+NNYy4G0DroQ8CI93xEynmb Cy/rtBbKNnlIMXYVwfHFuzv1lxQtIFelRZ1XEHQxSKL67bWrsmOXr4+CvG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=references :in-reply-to:mime-version:content-transfer-encoding:content-type :message-id:cc:from:subject:date:to; q=dns; s=mail; b=EU8MrIAsPc dima1zDAcuElxLwVYaXESlQggxX6A0cdTSUEPKlx6mUN1imBzq6ilnz81WwwH8Yx GZVBvMY6sAuteu4e1AlSaBnyrqkBTj+TGBF1hEwTTAf+EyavQixg/F9adzI0aGeV lfM0FdtwonFMQvG8SOBRoEdVMtUOarPUs= Received: from [192.168.1.208] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 9AF03E6448; Fri, 6 Apr 2012 14:11:03 +0100 (BST) References: <4F7ED7F4.5060509@zedat.fu-berlin.de> In-Reply-To: <4F7ED7F4.5060509@zedat.fu-berlin.de> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2355FE22-6725-4B7D-A56C-4FC0712022A7@cran.org.uk> X-Mailer: iPad Mail (9B176) From: Bruce Cran Date: Fri, 6 Apr 2012 14:11:03 +0100 To: "O. Hartmann" Cc: "freebsd-performance@freebsd.org" , Current FreeBSD Subject: Re: ECC memory driver in FreeBSD 10? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:11:12 -0000 On 6 Apr 2012, at 12:48, "O. Hartmann" wrote: > I'm looking for a way to force FreeBSD 10 to maintain/watch ECC errors > reported by UEFI (or BIOS). > Since ECC is said to be essential for server systems both in buisness > and science and I do not question this, I was wondering if I can not > report ECC errors via a watchdog or UEFI (ACPI?) report to syslog > facility on FreeBSD. > FreeBSD is supposed to be a server operating system, as far as I know, > so I believe there must be something which didn't have revealed itself > to me, yet. FreeBSD logs ECC errors it finds (I don't know how but I doubt it's via the B= IOS) by default: I had some RAM go bad a few months ago and messages appeare= d in dmesg. Is there something in addition you need? --=20 Bruce Cran= From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 14:24:11 2012 Return-Path: Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A57221065673; Fri, 6 Apr 2012 14:24:11 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD198FC0A; Fri, 6 Apr 2012 14:24:11 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q36EO9X2008158; Fri, 6 Apr 2012 14:24:10 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F7EFC89.1090805@FreeBSD.org> Date: Fri, 06 Apr 2012 16:24:09 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120404 Thunderbird/12.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-performance@FreeBSD.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:24:11 -0000 On 05.04.12 20:03, Arnaud Lacombe wrote: > Hi folks, Hi, > > Over the past months, I ran on a couple of unused box the > `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking > down various kind of regression/improvement. `hackbench' is a > scheduler + IPC test (socket xor pipe). It creates producers/consumers > groups and let a variable quantity of small messages flow happily. > Producers and consumers are either processes xor threads. [Lots of likely very interesting and valuable data.] > > Q4: "So, how can I get all the graph ?" > R4: All you need is git, a posix shell, a couple of utility (find, > sort, ...), a recent gnuplot, and a ruby interpreter. > Can you give us some hints on *how* to get the results? I checked the repo out but it's not immediately obvious what to do and how to get the graphs, as staring at thousands of numbers in lots of different files isn't exactly practical. Thanks, Florian From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 14:58:45 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC40F106564A; Fri, 6 Apr 2012 14:58:45 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 060368FC15; Fri, 6 Apr 2012 14:58:44 +0000 (UTC) Received: by lagv3 with SMTP id v3so3288049lag.13 for ; Fri, 06 Apr 2012 07:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RY/tOrBmrYcAKuXDHNQZXm/wCc67KP1ied9oEa8256g=; b=MZ6G32qk4FXkFqJlZCHyUdy9EwjXeup5KN9dW+cPklan8tJpbb89/bBBr1P0Sowqv0 L7uhzHmlnwNyLjhz7RGzP19GGR0o/aBysoWHxTHdGosZHt9VIQ7KI27qHL6zXuXQQaud s2ODs47xG6RrdnzJ5Iae1ENDsExz9+iqlm2/OXDII0HRSM5kLT7U2WoY73RkZYHVJuqJ 0RsfaKjQSLoE0Q8Q8h8aGUBEOS8IPbft/lMOlrtO69RC6lvbdEuVqHbBNT6JRVUNFZb/ yrsp8X8o4pOJ6nlHkQunFgcidklIM+nttf9Fhgs2x3RcbN2fFTzjkyCUom/kw0GWfezI cPQw== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr9305937lab.21.1333724323633; Fri, 06 Apr 2012 07:58:43 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.93.138 with HTTP; Fri, 6 Apr 2012 07:58:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 15:58:43 +0100 X-Google-Sender-Auth: WdYr8IUEZM3PNOlLwad926liIkw Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-performance@freebsd.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:58:45 -0000 Il 05 aprile 2012 19:03, Arnaud Lacombe ha scritto: > Hi folks, > > Over the past months, I ran on a couple of unused box the > `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking > down various kind of regression/improvement. `hackbench' is a > scheduler + IPC test (socket xor pipe). It creates producers/consumers > groups and let a variable quantity of small messages flow happily. > Producers and consumers are either processes xor threads. > > Tested platforms were > =C2=A0- Atom D510, Intel, (incomplete) > =C2=A0- Core 2 Quad Q9560, Intel > =C2=A0- Soekris net5501, AMD (incomplete) > =C2=A0- Xeon E5645, Intel (incomplete) > =C2=A0- Xeon E5620 (dual package), Intel > =C2=A0- Xeon E5-1650 (pending completion) > =C2=A0- Vortex86, DMP > > Tested kernel were: > =C2=A0- FreeBSD 7.4-RELEASE > =C2=A0- FreeBSD 8.2-RELEASE > =C2=A0- FreeBSD 9.0-RC3 and FreeBSD 9.0-RELEASE > =C2=A0- FreeBSD 10-CURRENT as of r231573 Which means you run 10-CURRENT with all the kernel debugging options on and MALLOC_DEBUG on? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 17:55:55 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A170C1065674; Fri, 6 Apr 2012 17:55:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E58B98FC17; Fri, 6 Apr 2012 17:55:54 +0000 (UTC) Received: by lbok6 with SMTP id k6so1105664lbo.13 for ; Fri, 06 Apr 2012 10:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U5IIy6Dzq32iIkifT9SpRqldXJ7lbfb1bpuhIzk9UtU=; b=bCr8y1sQcB5wCcZUZ6W5iho0TPgc4H+eFTbUNvNnu1RUm5GQajVHvJldr7GCtF5/31 MGtBoOnGJfwyrc5+x+7P5u6Jm1eDrZb8njsogXo8ogACg2SEzVrFQZ1T8ugnL6eE5V5H 9YP1DaKv7tyubRhfOMob1oZEUOzfb3j4/1sJw5NMVAYmkMlAghuMEYLXliypOeVa9G+E sokeYToww31FQSkB3qa1S5psB1xQe4Ni6juz1+tVEjXPEGGYSv0ymN0lwgZGfFjBVPxl O5lLHDHiBNuk7n/qhShltn52GyQJFdWbQkgkYQ5thd+HO/OyxLmf/uauqtSWSKrlRPvP DLig== MIME-Version: 1.0 Received: by 10.152.129.74 with SMTP id nu10mr9692941lab.50.1333734953707; Fri, 06 Apr 2012 10:55:53 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.93.138 with HTTP; Fri, 6 Apr 2012 10:55:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 18:55:53 +0100 X-Google-Sender-Auth: L9Rwr2iyymohv361d1b4FJtxieQ Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-performance@freebsd.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:55:55 -0000 Il 06 aprile 2012 18:54, Arnaud Lacombe ha scritto: > Hi, > > On Fri, Apr 6, 2012 at 10:58 AM, Attilio Rao wrote: >> Il 05 aprile 2012 19:03, Arnaud Lacombe ha scritto: >>> Hi folks, >>> >>> Over the past months, I ran on a couple of unused box the >>> `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking >>> down various kind of regression/improvement. `hackbench' is a >>> scheduler + IPC test (socket xor pipe). It creates producers/consumers >>> groups and let a variable quantity of small messages flow happily. >>> Producers and consumers are either processes xor threads. >>> >>> Tested platforms were >>> =C2=A0- Atom D510, Intel, (incomplete) >>> =C2=A0- Core 2 Quad Q9560, Intel >>> =C2=A0- Soekris net5501, AMD (incomplete) >>> =C2=A0- Xeon E5645, Intel (incomplete) >>> =C2=A0- Xeon E5620 (dual package), Intel >>> =C2=A0- Xeon E5-1650 (pending completion) >>> =C2=A0- Vortex86, DMP >>> >>> Tested kernel were: >>> =C2=A0- FreeBSD 7.4-RELEASE >>> =C2=A0- FreeBSD 8.2-RELEASE >>> =C2=A0- FreeBSD 9.0-RC3 and FreeBSD 9.0-RELEASE >>> =C2=A0- FreeBSD 10-CURRENT as of r231573 >> >> Which means you run 10-CURRENT with all the kernel debugging options >> on and MALLOC_DEBUG on? >> > I already answered that question. Namely: > > << > note: rule [I] is alleviated for -CURRENT kernels, which were built > with the same alteration made to GENERIC during the CURRENT->RELEASE > transition (ie. WITNESS and a couple of other option disabled). >>> > > this translates into the following patch (for amd64): Did you enable MALLOC_PRODUCTION and rebuilt libc? Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 17:51:37 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE4D01065674; Fri, 6 Apr 2012 17:51:37 +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 E5DE38FC1C; Fri, 6 Apr 2012 17:51:36 +0000 (UTC) Received: by wern13 with SMTP id n13so2048869wer.13 for ; Fri, 06 Apr 2012 10:51:35 -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=sy4X2n9Vjte6uyGHZnjJncZVeJKQ0sUwdWd91+vrgnM=; b=JnUyVp3qCr9rx2xIXIClzYqucSECW7Z437cbMTwmeD14bcp68L1xvNRqQKq++76QjW b/nCFcbXm6ZxququZUj4HaQqoXV7pQyxMORCtP6tY0hUSsFsX/PrekE92mDCAsPxbLj6 ivf7Vh/T48pcdaL6VkzepAy3zUyGzbaBU5D65POtmCEA11Abik9sNYgip24NOWLNGBQX avFTft7jPdSAW7EBIBT5tXGOSxXLWq922h+6NtL7758sRVLufVnxBc7nsQd0zVcIoUGn jgi/JvlVOA/qTmNpZi0yTqVhBRVEVTwGqcbvODSd/RGPqAqWIFiO5VeUhJFZBfwarq+B Ff5Q== MIME-Version: 1.0 Received: by 10.180.88.164 with SMTP id bh4mr21188790wib.22.1333734695909; Fri, 06 Apr 2012 10:51:35 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Fri, 6 Apr 2012 10:51:35 -0700 (PDT) In-Reply-To: <4F7EFC89.1090805@FreeBSD.org> References: <4F7EFC89.1090805@FreeBSD.org> Date: Fri, 6 Apr 2012 13:51:35 -0400 Message-ID: From: Arnaud Lacombe To: Florian Smeets Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 06 Apr 2012 18:04:34 +0000 Cc: freebsd-performance@freebsd.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:51:37 -0000 Hi, On Fri, Apr 6, 2012 at 10:24 AM, Florian Smeets wrote: > On 05.04.12 20:03, Arnaud Lacombe wrote: >> >> Hi folks, > > Hi, >> >> Over the past months, I ran on a couple of unused box the >> `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking >> down various kind of regression/improvement. `hackbench' is a >> scheduler + IPC test (socket xor pipe). It creates producers/consumers >> groups and let a variable quantity of small messages flow happily. >> Producers and consumers are either processes xor threads. > [Lots of likely very interesting and valuable data.] > >> >> Q4: "So, how can I get all the graph ?" >> R4: All you need is git, a posix shell, a couple of utility (find, >> sort, ...), a recent gnuplot, and a ruby interpreter. >> > > Can you give us some hints on *how* to get the results? I checked the repo > out but it's not immediately obvious what to do and how to get the graphs, > as staring at thousands of numbers in lots of different files isn't exactly > practical. > To just get all the graph, merge the runs/* branch you want, and just run the `results.sh' script: # sh results.sh To gather result, build `hackbench': # eval $(sed '/#gcc/!d; s/.//' hackbench.c) then, reboot in single mode, mount / read-write, adjust whatever you have to adjust and run the script: # sh hackbench.sh [light|medium|heavy] $(pwd)/hackbench this will run a complete iterations over all the possible tunables and gives you a `results.yml' that you can feed to the previous script. - Arnaud > Thanks, > Florian From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 17:54:05 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAFDF1065676; Fri, 6 Apr 2012 17:54:04 +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 1F62F8FC12; Fri, 6 Apr 2012 17:54:03 +0000 (UTC) Received: by wern13 with SMTP id n13so2050230wer.13 for ; Fri, 06 Apr 2012 10:54:03 -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:content-transfer-encoding; bh=bGl1TB2MEzWLr89JJq6YBka/b10BROPEWOOp50GVOco=; b=Zj/89UOjU8ZyOFZtHrhUtYPrh3I6EB1IsuL4GTaWF7IO39gfBOL6HjfbOYRH1kcnsA yYMxtV/xahwevqSs+s/5Ag/Th326nzjMQVeHwnjklu295zcKqhOVHQo4IaePz6J2fq1k Giyqxj4QCUrL5fo56S+LkUHKcaHpkYukJWoQsGASsBeW67QOwaitsB9dFHCktESH7FVu 3RUkZzufx1KCJcUDKSaFKnCrdSvfSvjmoEJRBYMAKkh8DhQIpkMojEW+bjdHkN7JPFvH ii33PjP0IBnvxdCxMmlW6ovfgmNUtgLCbiXPHgE0pU0D4Y5TO04D+961BMRuxoGzO5jK xQBg== MIME-Version: 1.0 Received: by 10.180.88.164 with SMTP id bh4mr21199994wib.22.1333734843168; Fri, 06 Apr 2012 10:54:03 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Fri, 6 Apr 2012 10:54:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 13:54:03 -0400 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 06 Apr 2012 18:04:46 +0000 Cc: freebsd-performance@freebsd.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:54:05 -0000 Hi, On Fri, Apr 6, 2012 at 10:58 AM, Attilio Rao wrote: > Il 05 aprile 2012 19:03, Arnaud Lacombe ha scritto: >> Hi folks, >> >> Over the past months, I ran on a couple of unused box the >> `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking >> down various kind of regression/improvement. `hackbench' is a >> scheduler + IPC test (socket xor pipe). It creates producers/consumers >> groups and let a variable quantity of small messages flow happily. >> Producers and consumers are either processes xor threads. >> >> Tested platforms were >> =A0- Atom D510, Intel, (incomplete) >> =A0- Core 2 Quad Q9560, Intel >> =A0- Soekris net5501, AMD (incomplete) >> =A0- Xeon E5645, Intel (incomplete) >> =A0- Xeon E5620 (dual package), Intel >> =A0- Xeon E5-1650 (pending completion) >> =A0- Vortex86, DMP >> >> Tested kernel were: >> =A0- FreeBSD 7.4-RELEASE >> =A0- FreeBSD 8.2-RELEASE >> =A0- FreeBSD 9.0-RC3 and FreeBSD 9.0-RELEASE >> =A0- FreeBSD 10-CURRENT as of r231573 > > Which means you run 10-CURRENT with all the kernel debugging options > on and MALLOC_DEBUG on? > I already answered that question. Namely: << note: rule [I] is alleviated for -CURRENT kernels, which were built with the same alteration made to GENERIC during the CURRENT->RELEASE transition (ie. WITNESS and a couple of other option disabled). >> this translates into the following patch (for amd64): diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 8db8e27..9d61f25 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -67,20 +67,6 @@ options MAC # TrustedBSD MAC Framework #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel -# Debugging support. Always need this: -options KDB # Enable kernel debugger support. -# For minimum debugger support (stable branch) use: -#options KDB_TRACE # Print a stack trace for a panic. -# For full debugger support use this instead: -options DDB # Support DDB. -options GDB # Support remote GDB. -options DEADLKRES # Enable the deadlock resolver -options INVARIANTS # Enable calls of extra sanity chec= king -options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS -options WITNESS # Enable checks to detect deadlocks and cycles -options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed -options MALLOC_DEBUG_MAXZONES=3D8 # Separate malloc(9) zones - Arnaud > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-performance@FreeBSD.ORG Fri Apr 6 18:04:02 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D6DB106564A; Fri, 6 Apr 2012 18:04:02 +0000 (UTC) (envelope-from lacombar@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 680BC8FC0A; Fri, 6 Apr 2012 18:04:01 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2379700wgb.31 for ; Fri, 06 Apr 2012 11:04:00 -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:content-transfer-encoding; bh=3PzoMRPyyjahlo1OYqsWyoEuQAvEao636Ytj6TFuz9A=; b=IHbzJ40+vLFGzEtFDKaxbTyBfkcy0jlIRSlpGuJX73YJ9alAmOPjO5IJWbmiuOkH+y xLRevHcz8K9KazWdM9wTlOQ/S1aZ9XPrOzzBS489TQ2EVQgNvhVTNhE54zJ/yBTyndSQ j7Z8btNo29SoMe+o9WHKuk59ifo/U0Z6eqHj/e+Uih6ldcutROBGihYAjxqD6sM9CIQw rNteRKEUeKPoZDF0wvVG1qJVZqtzudiVPyVWj5T9WQCRVGyKq/K3rDsnvhFJAQKAv9HP ngCtiNj80l5lkaGTj204ZkY/xafdF5jzIR+j2ShUg2Qt2ajwK2osJurhlhh/1oBwHXaa /REw== MIME-Version: 1.0 Received: by 10.180.88.164 with SMTP id bh4mr21248140wib.22.1333735440585; Fri, 06 Apr 2012 11:04:00 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Fri, 6 Apr 2012 11:04:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 14:04:00 -0400 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 06 Apr 2012 18:15:58 +0000 Cc: freebsd-performance@freebsd.org, FreeBSD Current Subject: Re: Scheduler + IPC performance on FreeBSD 7.4, 8.2, 9.0 and -CURRENT X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:04:02 -0000 Hi, On Fri, Apr 6, 2012 at 1:55 PM, Attilio Rao wrote: > Il 06 aprile 2012 18:54, Arnaud Lacombe ha scritto: >> Hi, >> >> On Fri, Apr 6, 2012 at 10:58 AM, Attilio Rao wrote= : >>> Il 05 aprile 2012 19:03, Arnaud Lacombe ha scritto= : >>>> Hi folks, >>>> >>>> Over the past months, I ran on a couple of unused box the >>>> `hackbench'[HACKBENCH] benchmark used by the Linux folks for tracking >>>> down various kind of regression/improvement. `hackbench' is a >>>> scheduler + IPC test (socket xor pipe). It creates producers/consumers >>>> groups and let a variable quantity of small messages flow happily. >>>> Producers and consumers are either processes xor threads. >>>> >>>> Tested platforms were >>>> =A0- Atom D510, Intel, (incomplete) >>>> =A0- Core 2 Quad Q9560, Intel >>>> =A0- Soekris net5501, AMD (incomplete) >>>> =A0- Xeon E5645, Intel (incomplete) >>>> =A0- Xeon E5620 (dual package), Intel >>>> =A0- Xeon E5-1650 (pending completion) >>>> =A0- Vortex86, DMP >>>> >>>> Tested kernel were: >>>> =A0- FreeBSD 7.4-RELEASE >>>> =A0- FreeBSD 8.2-RELEASE >>>> =A0- FreeBSD 9.0-RC3 and FreeBSD 9.0-RELEASE >>>> =A0- FreeBSD 10-CURRENT as of r231573 >>> >>> Which means you run 10-CURRENT with all the kernel debugging options >>> on and MALLOC_DEBUG on? >>> >> I already answered that question. Namely: >> >> << >> note: rule [I] is alleviated for -CURRENT kernels, which were built >> with the same alteration made to GENERIC during the CURRENT->RELEASE >> transition (ie. WITNESS and a couple of other option disabled). >>>> >> >> this translates into the following patch (for amd64): > > Did you enable MALLOC_PRODUCTION and rebuilt libc? > Userland originates from FreeBSD 7.4-RELEASE and was not changed for any of the tests, which are exclusively focused on the kernel. Doing otherwise would mean changing too many variables. - Arnaud From owner-freebsd-performance@FreeBSD.ORG Sat Apr 7 06:00:56 2012 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE2A8106567C; Sat, 7 Apr 2012 06:00:56 +0000 (UTC) (envelope-from ndenev@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 2F1958FC12; Sat, 7 Apr 2012 06:00:56 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2673042wgb.31 for ; Fri, 06 Apr 2012 23:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xYYzQckSuIme8bCQ/iDHIJoD8CJu2Ab/Zfe+4F2C+Lg=; b=m/EuCTO+cXpS/cd1rqtcIMupRLGaE4azPXanhT5lqUUXxJVRW1wOinYeySjDwdotg9 q0uZJFLAs5pSIUarTg02PM2fk+V8+VOQXNk04QVBGjnHr5sR8HKyBD+8uzJ/bTji6J0A wp5idFmRKEZUFcYiPIiOD/gkdizztd7SfQ7KnINZTW3tWNkCt+D+lBt3Uu1aFgj6G9mB 3H2y8lxkDzmV+xMMlLDj4Woxj+zC0jhivTMw9Q8/phpURxDQbUGMLr5Qd6j15R5Iwv0R glUGlKUwlnwLj6T+lllYIZS9gliURzOGew1omplmRACeLzmnCxo3n/kORbM9LYcTKTd1 KtyQ== Received: by 10.216.134.136 with SMTP id s8mr309358wei.6.1333778455324; Fri, 06 Apr 2012 23:00:55 -0700 (PDT) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id ff2sm19747422wib.9.2012.04.06.23.00.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Apr 2012 23:00:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <4F7ED7F4.5060509@zedat.fu-berlin.de> Date: Sat, 7 Apr 2012 09:00:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <687BFFD7-1456-4D7B-AFB2-356EE9B0D1DD@gmail.com> References: <4F7ED7F4.5060509@zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Sat, 07 Apr 2012 10:54:53 +0000 Cc: freebsd-performance@freebsd.org, Current FreeBSD Subject: Re: ECC memory driver in FreeBSD 10? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 06:00:56 -0000 On Apr 6, 2012, at 2:48 PM, O. Hartmann wrote: > I'm looking for a way to force FreeBSD 10 to maintain/watch ECC errors > reported by UEFI (or BIOS). > Since ECC is said to be essential for server systems both in buisness > and science and I do not question this, I was wondering if I can not > report ECC errors via a watchdog or UEFI (ACPI?) report to syslog > facility on FreeBSD. > FreeBSD is supposed to be a server operating system, as far as I know, > so I believe there must be something which didn't have revealed itself > to me, yet. >=20 > Thanks in advance, > Oliver >=20 If the hardware supports it, such errors should be logged as MCEs = (Machine Check Exceptions). I can say for sure it works pretty well with Dell servers, as I had one = with failing RAM module, and it reported the corrected ECC errors in dmesg.