Re: Benchmarks results for FreeBSD 11

[Erich Dollansky]

Hi,

On Sun, 21 Aug 2016 15:21:01 +1000
Kubilay Kocak  wrote:

> On 19/08/2016 9:34 AM, Erich Dollansky wrote:
> > 
> > I am sure that some know of this site:
> > 
> > http://www.phoronix.com/scan.php?page=article&item=2bsd-7linux-bench&num=4
> >
> >  I wonder about the results for FreeBSD. As I do not have 11 on my 
> > machines, a stupid question. Are there still some debugging aids 
> > enabled in 11?  
> 
> They're off in those versions, but did note compiler (and compiler
> args) differences between within most tests (See attachments) as you
> mentioned.
> 
the benchmark then compares the off-the-shelve distributions.
> 
> > I know that some of the results are caused by the use of CLang and
> > some of the results test applications/compilers and not operating
> > systems.  
> 
> gcc/clang tests and defaults in upstream build systems are almost
> certainly contributors. At a minimum it would be nice to see an
> attempt to standardise (force) compiler args across all OS runs for
> the same test, even if this doesn't prove to be perfect.

Yes, without, he compares compilers more than operating systems.
> 
> Separating or adding tests for the same tests using non-default
> compilers (in particular latest GCC versions from ports) so they match
> across OS's would also be valuable.
> 
> At a minimum it would be worth Michael highlighting the differences,
> and ideally removing these variables from the tests, even if they
> aren't default configurations. Though a test of out of the box
> configurations is still valuable, it can serve to muddy the
> underlying differences and make them tougher to isolate.

He never does this. I have no idea what he wants to achieve with his
benchmarking all the while as the results are very difficult to compare
with real life workloads.

Erich
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Benchmarks results for FreeBSD 11

[Kubilay Kocak]

On 19/08/2016 9:34 AM, Erich Dollansky wrote:
> Hi,
> 
> I am sure that some know of this site:
> 
> http://www.phoronix.com/scan.php?page=article&item=2bsd-7linux-bench&num=4
>
>  I wonder about the results for FreeBSD. As I do not have 11 on my 
> machines, a stupid question. Are there still some debugging aids 
> enabled in 11?

They're off in those versions, but did note compiler (and compiler args)
differences between within most tests (See attachments) as you mentioned.


> I know that some of the results are caused by the use of CLang and
> some of the results test applications/compilers and not operating
> systems.

gcc/clang tests and defaults in upstream build systems are almost
certainly contributors. At a minimum it would be nice to see an attempt
to standardise (force) compiler args across all OS runs for the same
test, even if this doesn't prove to be perfect.

Separating or adding tests for the same tests using non-default
compilers (in particular latest GCC versions from ports) so they match
across OS's would also be valuable.

At a minimum it would be worth Michael highlighting the differences, and
ideally removing these variables from the tests, even if they aren't
default configurations. Though a test of out of the box configurations
is still valuable, it can serve to muddy the underlying differences and
make them tougher to isolate.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

kern.proc.pathname failure while booting from zfs

[Frederic Chardon]

Hi

I see a strange interaction between zfs on root and kern.proc.pathname
on my laptop. Whenever I try to use gcore it fails with:
gcore 1023
gcore: kern.proc.pathname failure

However, gcore /usr/local/bin/zsh 1023 is working properly.

I made some tests booting from usb stick (fresh installworld, no
src.conf, no make.conf, GENERIC kernel)
What works: having / on ufs and importing a zfs pool later on.
What doesn't: having / on zfs, whatever the settings for checksum,
compression, or normalization.

Both 11-stable and 12-current behave this way. Current from may-june
worked properly.
adb, chromium and virtualbox as well stopped working at approximately
the same time, however I don't know if it is linked ("truss -f adb
start-server" shows that garbage is passed to execl after forking).

Any idea what's going on? Does anybody else see this?

Thanks!
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD 10.1 can't upgrade to FreeBSD 11-RC1 via freebsd-update

[Rainer Duffner]

FreeBSD 10.3 works.

FreeBSD 10.1 complains about a failed integrity check etc (which the EN was 
supposed to fix, I assume)


I did run freebsd-update to update to the latest patch-level and 
freebsd-version said, I was on p37.



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c

[Harry Schmalzbauer]

Bezüglich Rick Macklem's Nachricht vom 18.08.2016 02:03 (localtime):
>  Kostik wrote:
> [stuff snipped]
>> insmnque() performs the cleanup on its own, and that default cleanup isnot 
>> suitable >for the situation.  I think that insmntque1() would betterfit your 
>> requirements, your >need to move the common code into a helper.It seems that 
>> >unionfs_ins_cached_vnode() cleanup could reuse it.
> 
> I've attached an updated patch (untested like the last one). This one creates 
> a
> custom version insmntque_stddtr() that first calls unionfs_noderem() and then
> does the same stuff as insmntque_stddtr(). This looks like it does the 
> required
> stuff (unionfs_noderem() is what the unionfs VOP_RECLAIM() does).
> It switches the node back to using its own v_vnlock that is exclusively 
> locked,
> among other things.

Thanks a lot, today I gave it a try.

With this patch, one reproducable panic can still be easily triggered:
I have directory A unionfs_mounted under directory B.
Then I mount_unionfs the same directory A below another directory C.
panic: __lockmgr_args: downgrade a recursed lockmgr nfs @
/usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c:1905
Result is this backtrace, hardly helpful I guess:

#1  0x80ae5fd9 in kern_reboot (howto=260) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366
#2  0x80ae658b in vpanic (fmt=, ap=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759
#3  0x80ae63c3 in panic (fmt=0x0) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690
#4  0x80ab7ab7 in __lockmgr_args (lk=,
flags=, ilk=, wmesg=,
pri=, timo=, file=, line=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_lock.c:992
#5  0x80ba510c in vop_stdlock (ap=) at
lockmgr.h:98
#6  0x8111932d in VOP_LOCK1_APV (vop=,
a=) at vnode_if.c:2087
#7  0x80a18cfc in unionfs_lock (ap=0xfe007a3ba6a0) at
vnode_if.h:859
#8  0x8111932d in VOP_LOCK1_APV (vop=,
a=) at vnode_if.c:2087
#9  0x80bc9b93 in _vn_lock (vp=,
flags=66560, file=, line=) at
vnode_if.h:859
#10 0x80a18460 in unionfs_readdir (ap=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c:1531
#11 0x81118ecf in VOP_READDIR_APV (vop=,
a=) at vnode_if.c:1822
#12 0x80bc6e3b in kern_getdirentries (td=,
fd=, buf=0x800c3d000 ,
count=, basep=0xfe007a3ba980, residp=0x0)
at vnode_if.h:758
#13 0x80bc6bf8 in sys_getdirentries (td=0x0,
uap=0xfe007a3baa40) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/vfs_syscalls.c:3940
#14 0x80fad6b8 in amd64_syscall (td=,
traced=0) at subr_syscall.c:135
#15 0x80f8feab in Xfast_syscall () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:396
#16 0x00452eea in ?? ()
Previous frame inner to this frame (corrupt stack?

I ran your previous patch with for some time.
Similarly, mounting one directory below a 2nd mountpount crashed the
machine (forgot to config dumpdir, so can't compare backtrace with the
current patch).
Otherwise, at least with the previous patch, I haven't had any other
panic for about one week.

Thanks,

-Harry
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"