Slow on v210?
Tim Hogard
thogard at abnormal.com
Mon Apr 23 14:26:22 UTC 2012
I'm at the inital stages of looking into the problems here.
I just put Release 9.0 on a single CPU v210 and it is much slower
than I expected. A simple perl program runs at 1/6th the speed of
the Solaris 9 machine I'm testing aginst. Other things involing
basic utils also seem to run about that ratio. Compiles are also
very slow.
For testing I've got a Sol 9 dual 1.33 Ghz netra 210 with
4 gig of ram and a single 1.33 ghz v210 with 2 gig of ram.
My tests show both system have about 1 gig free and I run
4 processes per core:
#!/usr/bin/perl
foreach $i (1..1000000) {
$i{$i}=$i;
}
The FreeBSD 9.0 and perl 5.12 (from ports) with no load is running
much slower than the Sol 9 with perl 5.10 a few other things running.
sol$ time ./p
real 0m4.110s
user 0m3.430s
sys 0m0.610s
f9$ time ./p
27.24 real 6.10 user 21.00 sys
2 on f9 take 55 or so seconds, 4 on the dual cpu take about 8 seconds.
Other things also seem slower but I haven't benchmarked them but they should in the are ballpark.
The disks on the n210 are 2.5 and 3.5 on the v210. Both are 7200 rpm but everything is in cache.
The ram seems identical.
The freeBSD machine should not be 7 times slower.
Other issues:
1) The machine needed the vm.kmem_size="1024" in /etc/loader.conf or it wouldn't boot.
(http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2012-01/msg00414.html)
fixed by stopping boot and typing something like set vm.kmem_size="1024m" at
the laoder prompt.
2) base.txz just wouldn't end up with the right sha-256 hash even when checked
on other machines. Fixed by using net install.
Any hints?
Thanks,
-tim
http://web.abnormal.com
>
> Send freebsd-sparc64 mailing list submissions to
> freebsd-sparc64 at freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> or, via email, send a message with subject or body 'help' to
> freebsd-sparc64-request at freebsd.org
>
> You can reach the person managing the list at
> freebsd-sparc64-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-sparc64 digest..."
>
>
> Today's Topics:
>
> 1. Re: sparc64/165025: [PATCH] zfsboot support for sparc64
> (Marius Strobl)
> 2. Current problem reports assigned to
> freebsd-sparc64 at FreeBSD.org (FreeBSD bugmaster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 22 Apr 2012 20:40:13 GMT
> From: Marius Strobl <marius at alchemy.franken.de>
> Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64
> To: freebsd-sparc64 at FreeBSD.org
> Message-ID: <201204222040.q3MKeDtu098088 at freefall.freebsd.org>
>
> The following reply was made to PR sparc64/165025; it has been noted by GNATS.
>
> From: Marius Strobl <marius at alchemy.franken.de>
> To: Gavin Mu <gavin.mu at gmail.com>
> Cc: bug-followup at freebsd.org, Kurt Lidl <lidl at pix.net>
> Subject: Re: sparc64/165025: [PATCH] zfsboot support for sparc64
> Date: Sun, 22 Apr 2012 22:32:11 +0200
>
> On Thu, Apr 12, 2012 at 10:27:31PM +0800, Gavin Mu wrote:
> > On Mon, Mar 5, 2012 at 2:06 AM, Marius Strobl <marius at alchemy.franken.de> wrote:
> > > Typically, opening and closing devices via OFW causes quite a delay,
> > > the exact impact depends on the firmware version and the devices
> > > involved though. Therefore, it would be advisable to keep using the
> > > current approach of caching opened packages. In what way does this
> > > fail with ZFS?
> > The error message on Fire V100 is: Fast Data Access MMU Miss
> >
> > > Basically, IEEE 1275 just says that support for
> > > opening a package more than once depends on the particular package
> > > but nothing about concurrently opening different packages. Not
> > > being able to concurrently open different packages also doesn't
> > > make all that much of a sense as opening one package also means
> > > to subsequentially open all the parents up to the root if not
> > > already opened and I think to actually have tested opening disks
> > > concurrently when writing the current code. Could this fail due
> > > to one device actually being opened twice, once via the full path
> > > and once via its alias?
> > There is no such scene though the code lacks the checking for full
> > path/devalias.
> > I have tried many times to find the root cause but I think it is
> > difficult without open firmware knowledge.
> > currently I found that following scenes will cause this issue with my test code:
> > 1. do OF_seek(ihandle_t a) just after OF_close(ihandle_t b). in real
> > world, OF_seek(a) is the step to read ZFS data just after OF_close()
> > another disk during zfs init/probe.
> > 2. do OF_seek(ihandle_t a) just after OF_open("available controller
> > without disk"). For example there is no disk3 on my machine though
> > there is disk controller. OF_open("disk3:") will report:
> > Can't read disk label.
> > Can't open disk label package
> >
> > in ofw_disk.c, OF_close() has been commented out for powerpc
> > architecture, and can not find detail reason from code history, so I
> > am thinking if we need also disable OF_close() for sparc64.
>
> Hrm, some OFW implementations might have reference counting bugs,
> causing OF_close() to also close some parent(s) when these in fact
> are still used by another opened child device. Have you tried how
> it works when just commenting out the OF_close() in ofwd_close() but
> leaving the rest of ofw_disk.c as is? If that works, we probably
> can add a cleanup handler which closes all opened disk devices
> before leaving the loader, still taking advantage of caching opened
> disks.
>
> >
> > for OF_open("normal disk controller without disk") issue, I did not
> > find how to work around or fix yet.
>
> Currently, I can't think of a way to solve this with the available
> OFW interfaces. Have you checked whether OpenSolaris includes the
> source of the OFW ZFS loader bits and how it's done there or
> generally how a Solaris instalaltion handles this (f.e. does it
> create any additional aliases for ZFS providers and uses these
> instead etc)?
>
> >
> > Is there any documents about how this open firmware work? I googled
> > but can not find anything useful.
> >
>
> For the most part, there's just IEEE 1275. There once was a bit of
> related information on http://playground.sun.com/1275/, which
> unfortunately disappeared some time after Oracle took over.
>
> Marius
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Apr 2012 11:07:24 GMT
> From: FreeBSD bugmaster <bugmaster at FreeBSD.org>
> Subject: Current problem reports assigned to
> freebsd-sparc64 at FreeBSD.org
> To: freebsd-sparc64 at FreeBSD.org
> Message-ID: <201204231107.q3NB7On0047706 at freefall.freebsd.org>
>
> Note: to view an individual PR, use:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
>
> The following is a listing of current problems submitted by FreeBSD users.
> These represent problem reports covering all versions including
> experimental development code and obsolete releases.
>
>
> S Tracker Resp. Description
> --------------------------------------------------------------------------------
> o sparc/165025 sparc64 [PATCH] zfsboot support for sparc64
> o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500
> o sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from
> o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i
> o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller
> s sparc/139134 sparc64 kernel output corruption
> 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/71729 sparc64 printf in kernel thread causes panic on SPARC
>
> 10 problems total.
>
>
>
> ------------------------------
>
> _______________________________________________
> freebsd-sparc64 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe at freebsd.org"
>
>
> End of freebsd-sparc64 Digest, Vol 472, Issue 1
> ***********************************************
>
More information about the freebsd-sparc64
mailing list