From owner-freebsd-sparc64@FreeBSD.ORG Sun Jun 19 22:00:45 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAB8C106564A for ; Sun, 19 Jun 2011 22:00:45 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3DDFF8FC0C for ; Sun, 19 Jun 2011 22:00:44 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p5JM0apn021873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jun 2011 08:00:37 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p5JM0ZBU061591; Mon, 20 Jun 2011 08:00:35 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p5JM0Y3L061590; Mon, 20 Jun 2011 08:00:34 +1000 (EST) (envelope-from peter) Date: Mon, 20 Jun 2011 08:00:34 +1000 From: Peter Jeremy To: Marius Strobl Message-ID: <20110619220033.GA61397@server.vk2pj.dyndns.org> References: <20110526234728.GA69750@server.vk2pj.dyndns.org> <20110527120659.GA78000@alchemy.franken.de> <20110601231237.GA5267@server.vk2pj.dyndns.org> <20110608224801.GB35494@alchemy.franken.de> <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110615233445.GZ7064@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20110615233445.GZ7064@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 22:00:45 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jun-16 01:34:45 +0200, Marius Strobl wr= ote: >You could try whether the below patch sufficiently reduces the lock >coverage to avoid these. For stable/8 you'll probably need to apply >the second chunk by hand. Well, it lasted through 30 hours of 'make -j32 universe' (on its 7th cycle) before panicing with a 'spin lock held too long' on sched lock. Along the way, I got 4 isp_watchdog timeouts (and subsequent 'bad request handle' reports. Do you have any ideas why the panics aren't dropping into DDB? As a cross-check, I'm currently running 'make -j16 universe' on a 4 cpu V440 using the same kernel/world (unfortunately, I wasn't able to run this over the weekend). --=20 Peter Jeremy --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3+cYEACgkQ/opHv/APuIeSMwCfc9MHyg7tzG4m57ECZp5zR/US mygAn3MVlCjf2FAtgf4b80KTJHnHLwkU =P58C -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 20 11:07:11 2011 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E111065674 for ; Mon, 20 Jun 2011 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0217A8FC27 for ; Mon, 20 Jun 2011 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5KB7A6o098239 for ; Mon, 20 Jun 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5KB7Adh098237 for freebsd-sparc64@FreeBSD.org; Mon, 20 Jun 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Jun 2011 11:07:10 GMT Message-Id: <201106201107.p5KB7Adh098237@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/145211 sparc64 [panic] Memory modified after free o sparc/142102 sparc64 [nfs] [panic] FreeBSD 8.0 kernel panics on sparc64 whe o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 10 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 21 16:49:36 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAD7C106564A; Tue, 21 Jun 2011 16:49:36 +0000 (UTC) (envelope-from jasone@canonware.com) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id C82D28FC14; Tue, 21 Jun 2011 16:49:36 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id CCC012843A; Tue, 21 Jun 2011 09:32:39 -0700 (PDT) Message-ID: <4E00C7A7.8080704@canonware.com> Date: Tue, 21 Jun 2011 09:32:39 -0700 From: Jason Evans User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marius Strobl References: <20110616073138.GL31996@gradx.cs.jhu.edu> <20110616075319.GM31996@gradx.cs.jhu.edu> <20110617180713.GA5300@alchemy.franken.de> <20110617193129.GC4764@gradx.cs.jhu.edu> <20110617213532.GG7064@alchemy.franken.de> In-Reply-To: <20110617213532.GG7064@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nathaniel W Filardo , jasone@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: TLS bug? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:49:37 -0000 On 06/17/2011 02:35 PM, Marius Strobl wrote: > On Fri, Jun 17, 2011 at 03:31:29PM -0400, Nathaniel W Filardo wrote: >> On Fri, Jun 17, 2011 at 08:07:13PM +0200, Marius Strobl wrote: >>> Using bonnie++ I can't reproduce this (didn't try mysql) but I have >> >> I seem to have good luck reproducing it with "-r 5 -s 10 -x 10" by about the >> third iteration. > > Ok, with these parameters I can reproduce it. > >> >>> some TLS fixes for libthr I forgot about but could be relevant here >>> (most actually date back to 2008 when the base binutils didn't support >>> GNUTLS for sparc64 so I couldn't test them easily). Could you please >>> give a libthr build with the following patch a try? >>> http://people.freebsd.org/~marius/libthr_sparc64.diff >> >> Concurrent runs both with and without those diffs still asserted. >> Interestingly, libc's .tbss section, even after the assertion, is still full >> of zeros, so it looks like something stranger than a wild-write back to >> .tbss. I'll go diving through the tls allocation code again when I get a >> minute. >> > > In combination with the below patch bonnie++ survived 100 iterations > here. I'm not sure what this means though as I don't have much knowledge > about TLS, I merely implemented the necessary relocations. Could be > that malloc() actually requires the initial exec model for variant II. > Unfortunately, it's not documented why it was added for x86. > Jason, can you shed some light on this? > > Marius > > Index: malloc.c > =================================================================== > --- malloc.c (revision 219535) > +++ malloc.c (working copy) > @@ -234,7 +234,7 @@ > #ifdef __sparc64__ > # define LG_QUANTUM 4 > # define LG_SIZEOF_PTR 3 > -# define TLS_MODEL /* default */ > +# define TLS_MODEL __attribute__((tls_model("initial-exec"))) > #endif > #ifdef __amd64__ > # define LG_QUANTUM 4 > I added the initial-exec TLS_MODEL because it is faster than the default; jemalloc in no way depends on this for correctness though, so your patch is safe. Thanks, Jason From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 22 10:05:30 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 989431065670 for ; Wed, 22 Jun 2011 10:05:30 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 186CA8FC08 for ; Wed, 22 Jun 2011 10:05:29 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p5MA5PKO032432; Wed, 22 Jun 2011 12:05:25 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5MA5OmS032431; Wed, 22 Jun 2011 12:05:24 +0200 (CEST) (envelope-from marius) Date: Wed, 22 Jun 2011 12:05:24 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20110622100524.GO14797@alchemy.franken.de> References: <20110526234728.GA69750@server.vk2pj.dyndns.org> <20110527120659.GA78000@alchemy.franken.de> <20110601231237.GA5267@server.vk2pj.dyndns.org> <20110608224801.GB35494@alchemy.franken.de> <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110615233445.GZ7064@alchemy.franken.de> <20110619220033.GA61397@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110619220033.GA61397@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 10:05:30 -0000 On Mon, Jun 20, 2011 at 08:00:34AM +1000, Peter Jeremy wrote: > On 2011-Jun-16 01:34:45 +0200, Marius Strobl wrote: > >You could try whether the below patch sufficiently reduces the lock > >coverage to avoid these. For stable/8 you'll probably need to apply > >the second chunk by hand. > > Well, it lasted through 30 hours of 'make -j32 universe' (on its 7th > cycle) before panicing with a 'spin lock held too long' on sched lock. Okay, given that it considerably improves the situation though I suspect that the problem is that we instantly begin to fault on kernel mappings once we flush all unlocked TLB entries in order to get rid of the user mappings, which in case of cpu_switch() still is covered by sched_lock. That would mean that we should use a fine grained approach instead as the current one doesn't behave/ scale well even if sched_lock wasn't be (ab)used here. Could you please give the following patch a try on top of what you already have? http://people.freebsd.org/~marius/sparc64_flush_user_no_sledgehammer.diff Note that this version is incomplete in that it breaks compiling the loader so you won't be able to build world with it. > Along the way, I got 4 isp_watchdog timeouts (and subsequent 'bad > request handle' reports. > > Do you have any ideas why the panics aren't dropping into DDB? > No, not really. However, the remaining contenders are cpu_switch() and the scheduler itself and I'm not sure whether one can easily panic when in there. It would be interesting to know if you get the "timeout stopping cpus" in generic_stop_cpus(), compiling the whole kernel with DIAGNOSTIC is overkill though. Unfortunately, theres no way to "hard" stop Sun sun4u CPUs or emulate some NMI short of triggering a red state exception, which is rather hairy to recover from. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 23 06:04:38 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE8DE106564A for ; Thu, 23 Jun 2011 06:04:38 +0000 (UTC) (envelope-from peter.jeremy@alcatel-lucent.com) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by mx1.freebsd.org (Postfix) with ESMTP id 989748FC0C for ; Thu, 23 Jun 2011 06:04:38 +0000 (UTC) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5N5k3lq005739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Jun 2011 00:46:04 -0500 (CDT) Received: from unixmail.au.alcatel-lucent.com (unixmail.au.alcatel-lucent.com [139.188.42.130]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5N5jxKw012757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Jun 2011 00:46:03 -0500 Received: from insmb.au.alcatel-lucent.com (insmb.au.alcatel-lucent.com [139.188.42.184]) by unixmail.au.alcatel-lucent.com (8.13.8+Sun/8.13.3) with ESMTP id p5N5jxgK003033 for ; Thu, 23 Jun 2011 15:45:59 +1000 (EST) Received: from pjdesk.au.alcatel-lucent.com (pjdesk.au.alcatel-lucent.com [139.188.2.2]) by insmb.au.alcatel-lucent.com (8.13.8+Sun/8.13.8) with ESMTP id p5N5Uwi6029475; Thu, 23 Jun 2011 15:30:58 +1000 (EST) X-Bogosity: Ham, spamicity=0.000000 Received: from pjdesk.au.alcatel-lucent.com (localhost [127.0.0.1]) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4) with ESMTP id p5N5UrXF099833; Thu, 23 Jun 2011 15:30:53 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Received: (from pjeremy@localhost) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4/Submit) id p5N5Upga099832; Thu, 23 Jun 2011 15:30:51 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Date: Thu, 23 Jun 2011 15:30:51 +1000 From: Peter Jeremy To: freebsd-sparc64@freebsd.org Message-ID: <20110623053051.GL65891@pjdesk.au.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R+My9LyyhiUvIEro" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: SPARC64 context switching oddities X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 06:04:39 -0000 --R+My9LyyhiUvIEro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a tool that measures the rate at which a single-byte token can be passed between two processes via a socketpair and have been running multiple copies of it on an otherwise idle V890 (16-CPU, 64GB RAM running -current from about a week ago), capturing 'vmstat -s' output. In the process, I have found several oddities: 1) The number of context switches doesn't match my expectations. See http://i.imgur.com/TyU3j.jpg It starts out unexpectedly high (~184k switches/sec) and then drops to an unrealistically low value as the number of processes increases from 1 to about 20 pairs. It then very slowly increases. Based on one process writing a token to a second process requiring one context switch, I would expect the number of context switches to roughly match the green (based on token passing rate) or blue (based on syscall rate) lines. 2) The transfer rate dips initially then rises to a peak before tailing off. See http://i.imgur.com/zVcfu.jpg and http://i.imgur.com/DhMmV.jpg The red line shows the rate reported by the program and the green line shows the rate estimated from the syscall rate. I would expect a fairly flat peak from 1 to about 16 pairs (since there are 16 execution threads available) that then tailed off as scheduler overheads increased Can anyone offer an explanation for this behaviour? --=20 Peter Jeremy --R+My9LyyhiUvIEro Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4Cz4sACgkQ/opHv/APuIcdmQCgvUihaH9+kUezHeXFUE8FNLGW 21IAn1CIaVtvRNR/S5qsnCmpM5KxABgd =IkZT -----END PGP SIGNATURE----- --R+My9LyyhiUvIEro-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 23 10:53:48 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C78C11065670 for ; Thu, 23 Jun 2011 10:53:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3090F8FC17 for ; Thu, 23 Jun 2011 10:53:47 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p5NArhGJ038586; Thu, 23 Jun 2011 12:53:43 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5NArhWi038585; Thu, 23 Jun 2011 12:53:43 +0200 (CEST) (envelope-from marius) Date: Thu, 23 Jun 2011 12:53:43 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20110623105343.GA38525@alchemy.franken.de> References: <20110623053051.GL65891@pjdesk.au.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110623053051.GL65891@pjdesk.au.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: SPARC64 context switching oddities X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 10:53:48 -0000 On Thu, Jun 23, 2011 at 03:30:51PM +1000, Peter Jeremy wrote: > I have a tool that measures the rate at which a single-byte token can > be passed between two processes via a socketpair and have been running > multiple copies of it on an otherwise idle V890 (16-CPU, 64GB RAM > running -current from about a week ago), capturing 'vmstat -s' output. > In the process, I have found several oddities: > > 1) The number of context switches doesn't match my expectations. > See http://i.imgur.com/TyU3j.jpg > It starts out unexpectedly high (~184k switches/sec) and then drops to > an unrealistically low value as the number of processes increases from > 1 to about 20 pairs. It then very slowly increases. Based on one > process writing a token to a second process requiring one context > switch, I would expect the number of context switches to roughly match > the green (based on token passing rate) or blue (based on syscall > rate) lines. > > 2) The transfer rate dips initially then rises to a peak before tailing off. > See http://i.imgur.com/zVcfu.jpg and http://i.imgur.com/DhMmV.jpg > The red line shows the rate reported by the program and the green line > shows the rate estimated from the syscall rate. I would expect a fairly > flat peak from 1 to about 16 pairs (since there are 16 execution threads > available) that then tailed off as scheduler overheads increased > > Can anyone offer an explanation for this behaviour? > I guess you're better off trying to find someone who knows about the schedulers on arch@. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 23 10:53:56 2011 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBE7D1065670; Thu, 23 Jun 2011 10:53:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F61C8FC1B; Thu, 23 Jun 2011 10:53:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p5NArto8012841; Thu, 23 Jun 2011 06:53:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p5NArtfb012828; Thu, 23 Jun 2011 10:53:55 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 23 Jun 2011 10:53:55 GMT Message-Id: <201106231053.p5NArtfb012828@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 10:53:57 -0000 TB --- 2011-06-23 09:46:45 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-23 09:46:45 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-23 09:46:45 - cleaning the object tree TB --- 2011-06-23 09:47:01 - cvsupping the source tree TB --- 2011-06-23 09:47:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-23 09:47:48 - building world TB --- 2011-06-23 09:47:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 09:47:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 09:47:48 - TARGET=sparc64 TB --- 2011-06-23 09:47:48 - TARGET_ARCH=sparc64 TB --- 2011-06-23 09:47:48 - TZ=UTC TB --- 2011-06-23 09:47:48 - __MAKE_CONF=/dev/null TB --- 2011-06-23 09:47:48 - cd /src TB --- 2011-06-23 09:47:48 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 23 09:47:49 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jun 23 10:49:50 UTC 2011 TB --- 2011-06-23 10:49:50 - generating LINT kernel config TB --- 2011-06-23 10:49:50 - cd /src/sys/sparc64/conf TB --- 2011-06-23 10:49:50 - /usr/bin/make -B LINT TB --- 2011-06-23 10:49:50 - building LINT kernel TB --- 2011-06-23 10:49:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-23 10:49:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-23 10:49:50 - TARGET=sparc64 TB --- 2011-06-23 10:49:50 - TARGET_ARCH=sparc64 TB --- 2011-06-23 10:49:50 - TZ=UTC TB --- 2011-06-23 10:49:50 - __MAKE_CONF=/dev/null TB --- 2011-06-23 10:49:50 - cd /src TB --- 2011-06-23 10:49:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 23 10:49:50 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'isEepromValid': /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: implicit declaration of function 'HALDEBUG_G' /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: warning: nested extern declaration of 'HALDEBUG_G' [-Wnested-externs] /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: 'HAL_DEBUG_REGDOMAIN' undeclared (first use in this function) /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/ath_hal/ah_regdomain.c:170: error: for each function it appears in.) /src/sys/dev/ath/ath_hal/ah_regdomain.c: In function 'ath_hal_mapgsm': /src/sys/dev/ath/ath_hal/ah_regdomain.c:612: error: 'HAL_DEBUG_ANY' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-23 10:53:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-23 10:53:55 - ERROR: failed to build lint kernel TB --- 2011-06-23 10:53:55 - 3032.88 user 740.70 system 4030.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Jun 24 11:59:28 2011 Return-Path: Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B6761065672 for ; Fri, 24 Jun 2011 11:59:28 +0000 (UTC) (envelope-from elektronika5sale@wp.pl) Received: from mail01.home.net.pl (mail01.home.net.pl [62.129.252.11]) by mx1.freebsd.org (Postfix) with SMTP id E176C8FC17 for ; Fri, 24 Jun 2011 11:59:27 +0000 (UTC) Received: from abxj100.neoplus.adsl.tpnet.pl [83.9.3.100] (HELO aehj98.neoplus.adsl.tpnet.pl) by internetmail.home.pl [212.85.96.60] with SMTP (IdeaSmtpServer v0.70) id c091cd43df14e165; Fri, 24 Jun 2011 13:32:47 +0200 From: "Car Lab IMMO" To: "freebsd-sparc" MIME-Version: 1.0 Organization: Car Lab IMMO Date: Fri, 24 Jun 2011 13:32:47 +0200 Message-Id: <20110624115928.7B6761065672@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: BYPASS + SIMULATOR OF IMMOBILIZERS AND SEAT OCCUPANT DETECTOR - COMPANY OFFER X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 11:59:28 -0000 =20 NEW, BETTER, WITH ADDITIONAL FUNCTIONS: BYPASS - Audi, Seat, Skoda, VW + simulator of immobilizers and seat occupant detector 39 programs ! It turns on or turns off immobilizer through the diagnostic plug OBD a= nd it allows emergency start after connect pins of instrument cluster = or immo, it also additionally works as a simulator of immobilizers and= seat occupant detector. This device is unique, it works without quantitative restrictions (you= can use it repeatedly in many cars), it is produced in the European U= nion by company CarLabImmo. PACKAGE CONTAINS: 1. BYPASS + simulator of immobilizers and seat occupant detector , 2. leather etui, 3. CD with instructions =2E.. for only 525 EURO !!! Warning! Since this version of the device, any updates FREE! (client only covers shipping costs both ways) Please visit our online store: www.elektronika.renado.pl Regards, Electronic Services Iwona Piotrowska st. Szosowa 2c 74-320 Barlinek=20 mobile 0048 691 406 958 If you are not interested in innovations offered by our company, pleas= e disregard this message. We sincerely apologize people not interested= in the news, for your time and place in your inbox.