Re: Heads up: New C++ stack
David Chisnall thera...@freebsd.org writes: [...] libcxxrt and libc++ are now in contrib and building with the base system, but are not used by anything (and are only built if you set WITH_LIBCPLUSPLUS=yes when building world, not by default). If you want to test some code with the new stack, you need to build it and then specify -stdlib=libc++ to clang++ (both when compiling and linking). Does the option work when building world with -jX ? $ make -sj2 buildworld [...] === lib/libcompiler_rt (obj,depend,all,install) === lib/libc (obj,depend,all,install) === lib/libcxxrt (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [libcxxrt.so.1] Error code 1 And later in silent build --verbose in LDFLAGS for libc++ produces noise that's neither a warning nor a build directory. === lib/libcxxrt (all) === lib/libc++ (all) FreeBSD clang version 3.0 (tags/RELEASE_30/final 145349) 20111210 Target: x86_64-unknown-freebsd10.0 Thread model: posix /usr/obj/usr/src/tmp/usr/bin/ld --eh-frame-hdr -Bshareable -o libc++.so.1 /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginS.o -L/usr/obj/usr/src/lib/libc++/../libcxxrt/ -L/usr/obj/usr/src/tmp/usr/lib -x --fatal-warnings --warn-shared-textrel -soname libc++.so.1 valarray.So utility.So strstream.So regex.So random.So iostream.So debug.So chrono.So bind.So algorithm.So hash.So thread.So future.So new.So locale.So typeinfo.So mutex.So memory.So ios.So condition_variable.So system_error.So string.So stdexcept.So exception.So -lcxxrt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/obj/usr/src/tmp/usr/lib/crtendS.o /usr/obj/usr/src/tmp/usr/lib/crtn.o ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Sun Dec 18 11, Andrey Chernov wrote: On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. This issue not about slow machine under load, because the same slow machine under exact the same load, but with SCHED_4BSD is very fast to response interactively. I think we should not misinterpret interactivity with speed. I see no big speed (i.e. compilation time) differences, switching schedulers, but see big _interactivity_ difference. ULE in general tends to underestimate interactive processes in favour of background ones. It perhaps helps to compilation, but looks like slowpoke OS from the interactive user experience. +1 i've also experienced issues with ULE and performed several tests to compare it to the historical 4BSD scheduler. the difference between the two does *not* seem to be speed (at least not a huge difference), but interactivity. one of the tests i performed was the following ttyv0: untar a *huge* (+10G) archive ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory contains a lot of files. i used direcory = /var/db/portsnap, because that directory contains 23117 files on my machine. measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes 15 seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. io operations usually get a high priority, because statistics have shown that - unlike computational tasks - io intensive tasks only run for a small fraction of time and then exit: read data - change data - writeback data. so SCHED_ULE might take these statistics too literaly and gives tasks like bsdtar(1) (in my case) too many ressources, so other tasks which require io are struggling to get some ressources assigned to them (ls(1) in my case). of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 testsuite. your whole system will grind to a halt. mouse input drops below 1 HZ. even after killing all the stress2 tests, it will take a few minutes after the system becomes snappy again. cheers. alex -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Sun Dec 18 11, Alexander Best wrote: On Sun Dec 18 11, Andrey Chernov wrote: On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. This issue not about slow machine under load, because the same slow machine under exact the same load, but with SCHED_4BSD is very fast to response interactively. I think we should not misinterpret interactivity with speed. I see no big speed (i.e. compilation time) differences, switching schedulers, but see big _interactivity_ difference. ULE in general tends to underestimate interactive processes in favour of background ones. It perhaps helps to compilation, but looks like slowpoke OS from the interactive user experience. +1 i've also experienced issues with ULE and performed several tests to compare it to the historical 4BSD scheduler. the difference between the two does *not* seem to be speed (at least not a huge difference), but interactivity. one of the tests i performed was the following ttyv0: untar a *huge* (+10G) archive ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory contains a lot of files. i used direcory = /var/db/portsnap, because s/portsnap/portsnap\/files/ that directory contains 23117 files on my machine. measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes 15 seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. io operations usually get a high priority, because statistics have shown that - unlike computational tasks - io intensive tasks only run for a small fraction of time and then exit: read data - change data - writeback data. so SCHED_ULE might take these statistics too literaly and gives tasks like bsdtar(1) (in my case) too many ressources, so other tasks which require io are struggling to get some ressources assigned to them (ls(1) in my case). of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 testsuite. your whole system will grind to a halt. mouse input drops below 1 HZ. even after killing all the stress2 tests, it will take a few minutes after the system becomes snappy again. cheers. alex -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On 18/12/2011 10:34, Adrian Chadd wrote: I applaud reppie for trying to make it as easy as possible for people to use KTR to provide scheduler traces for him to go digging with, so please, if you have these issues and you can absolutely reproduce them, please follow his instructions and work with him to get him what he needs. Who's 'reppie'? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662
On 12/18/11 02:45, Alexander Kabaev wrote: On Sun, 18 Dec 2011 01:09:00 +0100 O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sleeping thread (tid 100033, pid 16) owns a non sleepable lock panic: sleeping thread cpuid = 0 PID 16 is always USB on my box. You really need to give us a backtrace when you quote panics. It is impossible to make any sense of the above panic message without more context. Sorry, will do this immediately when I'm back in the lab. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: SCHED_ULE should not be the default
On 12/18/11 03:37, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I reported ages ago several problems using SCHED_ULE on FreeBSD 8/9 when doing heavy I/O, either disk or network bound (that time I realised the problem on servers doing heavy disk I/O or net I/O). It was suspected that X could be the problem, but we also have a Dell PowerEdge 1950III running FreeBSD 8.2-STABLE (by next week 9.0-RC[2/3]/STABLE) without X, but the same problems, but no so prominent as with X. The box has 8 cores, 4 cores per socket each and 16 GB RAM, SAS 6/iR controller and two PCI-X attached Broacom NexTreme NICs, so the hardware shouldn't be any kind of trouble. But that time (over the past two years for now), the problem was considered a personal problem. Bah! By the beginning of next year my working group expects new hardware. Since we use for Linux for scientific work (due to OpenCL and CUDA on TESLA cards), I can't use the Blade system. The boxes I expect is one Dell Precission T7500, 96 GB RAM, two sockets, two Westmere XEONs each socket with a summary of 12 cores/24 threads. I'll start a dual OS installation with FreeBSD 10 and the most recent Suse (since the development is mostly done by my colleagues on Suse for the C2075 TESLA board, I need Suse Linux). I will then being capable of performing some benchmarks on both boxes on the very same hardware. The other box will be my desk's box, a brand new Sandy-Bridge E CPU (i7-3960X) with 32 GB RAM. I'm also inclined to install a dual boot box (I rejected this up to now since I do not like to install GRUB2 for having multiboot when using GPT on FreeBSD). The box will run with FreeBSD 9 and an Ubuntu or Gentoo Linux, if. I'm unsure in the question of Linux, but I tend to have Gentoo for compiling everything myself. On this box, I also can perform benchmarks with several setups. I see forward getting some help and/or tips to proof the issues we discussed here. Oliver signature.asc Description: OpenPGP digital signature
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-12-18 15:26:46 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-12-18 15:26:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-12-18 15:26:46 - cleaning the object tree TB --- 2011-12-18 15:26:57 - cvsupping the source tree TB --- 2011-12-18 15:26:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-12-18 15:27:43 - building world TB --- 2011-12-18 15:27:43 - CROSS_BUILD_TESTING=YES TB --- 2011-12-18 15:27:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-18 15:27:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-18 15:27:43 - SRCCONF=/dev/null TB --- 2011-12-18 15:27:43 - TARGET=sparc64 TB --- 2011-12-18 15:27:43 - TARGET_ARCH=sparc64 TB --- 2011-12-18 15:27:43 - TZ=UTC TB --- 2011-12-18 15:27:43 - __MAKE_CONF=/dev/null TB --- 2011-12-18 15:27:43 - cd /src TB --- 2011-12-18 15:27:43 - /usr/bin/make -B buildworld World build started on Sun Dec 18 15:27:44 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 Sun Dec 18 16:25:50 UTC 2011 TB --- 2011-12-18 16:25:50 - generating LINT kernel config TB --- 2011-12-18 16:25:50 - cd /src/sys/sparc64/conf TB --- 2011-12-18 16:25:50 - /usr/bin/make -B LINT TB --- 2011-12-18 16:25:50 - cd /src/sys/sparc64/conf TB --- 2011-12-18 16:25:50 - /usr/sbin/config -m LINT TB --- 2011-12-18 16:25:50 - building LINT kernel TB --- 2011-12-18 16:25:50 - CROSS_BUILD_TESTING=YES TB --- 2011-12-18 16:25:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-12-18 16:25:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-12-18 16:25:50 - SRCCONF=/dev/null TB --- 2011-12-18 16:25:50 - TARGET=sparc64 TB --- 2011-12-18 16:25:50 - TARGET_ARCH=sparc64 TB --- 2011-12-18 16:25:50 - TZ=UTC TB --- 2011-12-18 16:25:50 - __MAKE_CONF=/dev/null TB --- 2011-12-18 16:25:50 - cd /src TB --- 2011-12-18 16:25:50 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Dec 18 16:25: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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors In file included from /src/sys/dev/e1000/if_em.c:400: /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *' pointer /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member 'dt_mt' in something not a structure or union *** 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-12-18 16:30:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-12-18 16:30:37 - ERROR: failed to build LINT kernel TB --- 2011-12-18 16:30:37 - 3031.62 user
Re: svn commit: r228576 - in head: . sys/boot/forth sys/modules sys/modules/carp sys/modules/if_carp
Alexander, On Sat, Dec 17, 2011 at 03:08:43PM +0100, Alexander Leidinger wrote: A we never had a kernel part in the list. Reinstallkernel is not a valid target after updating the sources. The renaming will only take effekt after updating. And we already hat issues because the list was too long. A Your entry for the carp module is completely out of question for this list. Please remove it. The file /boot/kernel/if_carp.ko had been installed on older installations. It is not overwritten now. Thus, it may happen in a some weird case, that it is left intact. 'make installkernel' is not the only way to upgrade FreeBSD. To cover these potential cases I have added an entry. This entry doesn't hurt anybody or anything. The argument for getting list of ObsoleteFiles.inc can't be taken seriously. The fact is that this file is going to instantly grow in any forseen future. It is never going to get shorter. Thus, if we are getting problems with the list getting too long, then we need to enhance the script that delete old files, not try to reduce it by 0.0235% removing one of recent entries, that is uncertain. I am adding current@ to CC, may be someone can take role of negotiator on this issue, or just has opinion. A A Bye, A Alexander. A A -- A Send via an Android device, please forgive brevity and typographic and spelling errors. Gleb Smirnoff gleb...@freebsd.org hat geschrieben: Alexander, A A On Fri, Dec 16, 2011 at 05:49:03PM +0100, Alexander Leidinger wrote: A A the ObsoleteFiles part ist not necessary, please remove. The installkernel moves the old stuff to kernel.old. A A I know that it does, and for 99% people this entry won't be needed. A But let it be here for those, who install new kernel some other way, A for example 'make reinstallkernel' or even copying by hand. A A The superfluous entry in ObsoleteFiles.inc has zero negative impact, A anyway. A A -- A Totus tuus, Glebius. A -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on sparc64/sparc64
FreeBSD Tinderbox tinder...@freebsd.org writes: In file included from /src/sys/dev/e1000/if_em.c:400: /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *' pointer /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member 'dt_mt' in something not a structure or union *** Error code 1 I made a mistake when I added support for additional LINT kernels (e.g. LINT-NOINET) so the additional kernels got built, but plain LINT didn't. As a result, this error has gone unnoticed by the tinderbox, even though it's been there for quite a while (or so I've been told). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
Hi, What Attilllo and others need are KTR traces in the most stripped down example of interactive-busting workload you can find. Eg: if you're doing 32 concurrent buildworlds and trying to test interactivity - fine, but that's going to result in a lot of KTR stuff. If you can reproduce it using a dd via /dev/null and /dev/random (like another poster did) with nothing else running, then even better. If you can do it without X running, even better. I honestly suggest ignoring benchmarks for now and concentrating on interactivity. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
openpam oddity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any ideas why courier-authdaemon is now reporting .. authdaemond: in openpam_dynamic(): No error: 0 authdaemond: in openpam_load_module(): no pam_unix.so found I've recompiled libpam and courier from scratch :-( imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7uSZYACgkQQv9rrgRC1JIrRQCgqygegBs0ibpRs83I+OwnDDiC LPMAn33nPgvJFqNxPOFXlzNL27hHVv/0 =Pp8J -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: openpam oddity?
On Sun, Dec 18, 2011 at 12:14 PM, Michael Butler i...@protected-networks.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any ideas why courier-authdaemon is now reporting .. authdaemond: in openpam_dynamic(): No error: 0 authdaemond: in openpam_load_module(): no pam_unix.so found I've recompiled libpam and courier from scratch :-( What version of CURRENT are you using? -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: openpam oddity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/18/11 15:20, Garrett Cooper wrote: On Sun, Dec 18, 2011 at 12:14 PM, Michael Butler i...@protected-networks.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any ideas why courier-authdaemon is now reporting .. authdaemond: in openpam_dynamic(): No error: 0 authdaemond: in openpam_load_module(): no pam_unix.so found I've recompiled libpam and courier from scratch :-( What version of CURRENT are you using? -Garrett SVN r228663: Sat Dec 17 17:33:23 EST 2011 imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7uS4MACgkQQv9rrgRC1JKmmQCfTn4S4CNBKtcDAje9nrGtvk+/ vdAAoKaAENaXFvSOrIycJrgqv1t878Hp =K7Yq -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Wed, 14 Dec 2011, Ivan Klymenko wrote:
?? Wed, 14 Dec 2011 00:04:42 +0100
Jilles Tjoelker jil...@stack.nl ??:
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
If the algorithm ULE does not contain problems - it means the
problem has Core2Duo, or in a piece of code that uses the ULE
scheduler. I already wrote in a mailing list that specifically in
my case (Core2Duo) partially helps the following patch:
--- sched_ule.c.orig2011-11-24 18:11:48.0 +0200
+++ sched_ule.c 2011-12-10 22:47:08.0 +0200
...
@@ -2118,13 +2119,21 @@
struct td_sched *ts;
THREAD_LOCK_ASSERT(td, MA_OWNED);
+ if (td-td_pri_class PRI_FIFO_BIT)
+ return;
+ ts = td-td_sched;
+ /*
+* We used up one time slice.
+*/
+ if (--ts-ts_slice 0)
+ return;
This skips most of the periodic functionality (long term load
balancer, saving switch count (?), insert index (?), interactivity
score update for long running thread) if the thread is not going to
be rescheduled right now.
It looks wrong but it is a data point if it helps your workload.
Yes, I did it for as long as possible to delay the execution of the code in
section:
I don't understand what you are doing here, but recently noticed that
the timeslicing in SCHED_4BSD is completely broken. This bug may be a
feature. SCHED_4BSD doesn't have its own timeslice counter like ts_slice
above. It uses `switchticks' instead. But switchticks hasn't been usable
for this purpose since long before SCHED_4BSD started using it for this
purpose. switchticks is reset on every context switch, so it is useless
for almost all purposes -- any interrupt activity on a non-fast interrupt
clobbers it.
Removing the check of ts_slice in the above and always returning might
give a similar bug to the SCHED_4BSD one.
I noticed this while looking for bugs in realtime scheduling. In the
above, returning early for PRI_FIFO_BIT also skips most of the periodic
functionality. In SCHED_4BSD, returning early is the usual case, so
the PRI_FIFO_BIT might as well not be checked, and it is the unusual
fifo scheduling case (which is supposed to only apply to realtime
priority threads) which has a chance of working as intended, while the
usual roundrobin case degenerates to an impure form of fifo scheduling
(iit is impure since priority decay still works so it is only fifo
among threads of the same priority).
...
@@ -2144,9 +2153,6 @@
if
(TAILQ_EMPTY(tdq-tdq_timeshare.rq_queues[tdq-tdq_ridx]))
tdq-tdq_ridx = tdq-tdq_idx; }
- ts = td-td_sched;
- if (td-td_pri_class PRI_FIFO_BIT)
- return;
if (PRI_BASE(td-td_pri_class) == PRI_TIMESHARE) {
/*
* We used a tick; charge it to the thread so
@@ -2157,11 +2163,6 @@
sched_priority(td);
}
/*
-* We used up one time slice.
-*/
- if (--ts-ts_slice 0)
- return;
- /*
* We're out of time, force a requeue at userret().
*/
ts-ts_slice = sched_slice;
With the ts_slice check here before you moved it, removing it might
give buggy behaviour closer to SCHED_4BSD.
and refusal to use options FULL_PREEMPTION
4-5 years ago, I found that any form of PREMPTION was a pessimization
for at least makeworld (since it caused too many context switches).
PREEMPTION was needed for the !SMP case, at least partly because of
the broken switchticks (switchticks, when it works, gives voluntary
yielding by some CPU hogs in the kernel. PREEMPTION, if it works,
should do this better). So I used PREEMPTION in the !SMP case and
not for the SMP case. I didn't worry about the CPU hogs in the SMP
case since it is rare to have more than 1 of them and 1 will use at
most 1/2 of a multi-CPU system.
But no one has unsubscribed to my letter, my patch helps or not in
the case of Core2Duo...
There is a suspicion that the problems stem from the sections of
code associated with the SMP...
Maybe I'm in something wrong, but I want to help in solving this
problem ...
The main point of SCHED_ULE is to give better affinity for multi-CPU
systems. But the `multi' apparently needs to be strictly more than
2 for it to brak even.
Bruce___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel michael.lara...@phoronix.com: On 12/15/2011 02:48 AM, Michael Ross wrote: Anyway these tests were performed on different hardware, FWIW. And with different filesystems, different compilers, different GUIs... No, the same hardware was used for each OS. The picture under the heading System Hardware / Software does not reflect that. Motherboard description differs, Chipset description for FreeBSD is empty. Regards, Michael In terms of the software, the stock software stack for each OS was used. -- Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/15/2011 04:41 AM, Michael Ross wrote: Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel michael.lara...@phoronix.com: On 12/15/2011 02:48 AM, Michael Ross wrote: Anyway these tests were performed on different hardware, FWIW. And with different filesystems, different compilers, different GUIs... No, the same hardware was used for each OS. The picture under the heading System Hardware / Software does not reflect that. Motherboard description differs, Chipset description for FreeBSD is empty. I was the on that carried out the testing and know that it was on the same system. All of the testing, including the system tables, is fully automated. Under FreeBSD sometimes the parsing of some component strings isn't as nice as Linux and other supported operating systems by the Phoronix Test Suite. For the BSD motherboard string parsing it's grabbing hw.vendor/hw.product from sysctl. Is there a better place to read the motherboard DMI information from? -- Michael Regards, Michael In terms of the software, the stock software stack for each OS was used. -- Michael ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Am 15.12.2011, 11:55 Uhr, schrieb Michael Larabel michael.lara...@phoronix.com: On 12/15/2011 04:41 AM, Michael Ross wrote: Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel michael.lara...@phoronix.com: On 12/15/2011 02:48 AM, Michael Ross wrote: Anyway these tests were performed on different hardware, FWIW. And with different filesystems, different compilers, different GUIs... No, the same hardware was used for each OS. The picture under the heading System Hardware / Software does not reflect that. Motherboard description differs, Chipset description for FreeBSD is empty. I was the on that carried out the testing and know that it was on the same system. No offense. I'm not doubting you. But I didn't know this: All of the testing, including the system tables, is fully automated. Under FreeBSD sometimes the parsing of some component strings isn't as nice as Linux and other supported operating systems by the Phoronix Test Suite. For the BSD motherboard string parsing it's grabbing hw.vendor/hw.product from sysctl. so maybe you can understand how I got my impression. NVidia Audio and Realtek Audio. Looks different to me :-) Is there a better place to read the motherboard DMI information from? Following Steven Hartlands' suggestion, from one of my machines: /usr/ports/sysutils/dmidecode/#sysctl -a | egrep hw.vendor|hw.product /usr/ports/sysutils/dmidecode/#dmidecode -t 2 # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: FUJITSU Product Name: D2759 Version: S26361-D2759-A13 WGS04 GS02 Serial Number: 35838599 Asset Tag: - Features: Board is a hosting board Board is removable Location In Chassis: - Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Nice. Didn't know about that. Regards, Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hi, all, Am 15.12.2011 um 12:18 schrieb Michael Ross: Following Steven Hartlands' suggestion, from one of my machines: /usr/ports/sysutils/dmidecode/#sysctl -a | egrep hw.vendor|hw.product /usr/ports/sysutils/dmidecode/#dmidecode -t 2 # dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: FUJITSU Product Name: D2759 Version: S26361-D2759-A13 WGS04 GS02 Serial Number: 35838599 Asset Tag: - Features: Board is a hosting board Board is removable Location In Chassis: - Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Without the need to install an additional port: datatomb2# kenv … smbios.bios.reldate=11/03/2011 smbios.bios.vendor=FUJITSU // American Megatrends Inc. smbios.bios.version=V4.6.4.1 R1.18.0 for D3034-A1x smbios.chassis.maker=FUJITSU smbios.chassis.serial=YLAP004857 smbios.chassis.tag=System Asset Tag smbios.chassis.version=RX100S7R2 smbios.memory.enabled=8388608 smbios.planar.maker=FUJITSU smbios.planar.product=D3034-A1 smbios.planar.serial=LJ1B-P00996 smbios.planar.version=S26361-D3034-A100 WGS01 GS02 smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=FUJITSU smbios.system.product=PRIMERGY RX100 S7 smbios.system.serial=YLAP004857 smbios.system.uuid=f0493081-f5ca-e011-b8a5-a1c4d143da5f smbios.system.version=GS02 smbios.version=2.7 … Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thu, Dec 15, 2011 at 04:55:16AM -0600, Michael Larabel wrote:
On 12/15/2011 04:41 AM, Michael Ross wrote:
Am 15.12.2011, 11:10 Uhr, schrieb Michael Larabel
michael.lara...@phoronix.com:
On 12/15/2011 02:48 AM, Michael Ross wrote:
Anyway these tests were performed on different hardware, FWIW.
And with different filesystems, different compilers, different GUIs...
No, the same hardware was used for each OS.
The picture under the heading System Hardware / Software does
not reflect that.
Motherboard description differs, Chipset description for FreeBSD
is empty.
I was the on that carried out the testing and know that it was on
the same system.
All of the testing, including the system tables, is fully automated.
Under FreeBSD sometimes the parsing of some component strings isn't
as nice as Linux and other supported operating systems by the
Phoronix Test Suite. For the BSD motherboard string parsing it's
grabbing hw.vendor/hw.product from sysctl.
Is there a better place to read the motherboard DMI information from?
I *think* what you're referring to is SMBIOS strings -- and these are
available from kenv(1) / kenv(2), not sysctl. But keep reading for why
SMBIOS data is not 100% reliable (greatly depends on the hardware). For
actual device strings/etc. for all devices on busses (PCI, AGP, etc.)
you can use pciconf -lvcb.
That's about as good as it's going to get via software. SMBIOS data
(e.g. smbios.{bios,chassis,planar,system}) is never going to give you
fully-identifiable data; I can point you to tons of systems where the
data inserted there is nonsense, sometimes even just ASCII spaces (and
that is the fault of the system vendor/BIOS manufacturer, not FreeBSD).
Sometimes identical strings are used across completely different
systems/boards (sometimes even server-class boards like ones from
Supermicro). And PCI vendor strings don't give you things like speeds,
frequency/voltages, etc.. Sometimes this matters. For example (just
making something up): the video benchmark was horrible on FreeBSD,
when in fact it turned out that a run of pciconf -lvcb showed your
PCIe card was running at x4 link speed instead of x16.
The best place to get your specifications from are:
* The box
* The physical hardware (by physically inspecting it)
* The user manual / product documentation/
* Purchase orders from whoever bought the hardware
* And, of course, operational speed (if possible) from the OS/userland
utilities
When I read a benchmark/review, I have to assume the person is doing
them on a system they have 100% control over, all the way down to the
hardware. Thus, they should know what exact hardware they have.
Also, when publishing results online, you should take the time to
proofread everything (with a 2nd set of eyes if possible) and be patient
and thorough. People like accuracy, especially when there's hard
data/evidence to back it up that can be made available for download.
Try to understand: so many review-esque sites consist of individuals who
do not understand even remotely what they're doing.
I'm going to give you two examples -- one personal, one word-of-mouth
but from someone I trust dearly.
I have a reverse analysis of Anantech's Intel 510 SSD review that has been
sitting in my draft folder on my blog for a month now because I'm
downright afraid to publish how their data seems completely and totally
wrong (with evidence to prove it). I'm afraid/stalling because I want
to make absolutely damn sure I'm not missing some key piece of evidence
that explains it, and I've had multiple people read it and go ...wow, I
didn't notice that, that benchmark data makes no sense, but I'm STILL
reluctant. The last thing I want to do is publish something that
sparks a controversy where it turns out I'm wrong (and I AM wrong, quite
often!).
As for the other:
http://www.overclockers.com/bulldozer-architecture-explained/
The author of this review talks about CPU arch and is praised for
writing a wonderful article that speaks the truth. But sadly that
doesn't appear to be the case. A colleague of mine is long-time friends
with another individual who is getting his Ph.D in computer architecture
and recently submit a paper to a journal (and was published/accepted)
which has published papers on things like RAID (when it was first
introduced as a concept/method), and hardware watchpoints. Said
individual read the above review and described it as, quote, the
worst article on computer architecture on the entire Internet. One of
the amusing quotes (that got me laughing since I did understand it; my
understanding of CPUs on a silicon level is limited, I'm just an old
65xxx assembly programmer...) was how the article states this is the
first time AMD has implemented branch prediction. Sigh.
Here's the kicker: said individual immediately recognised that the
article was a near dry cut-and-paste from one of two commonly-used
computer architecture books in
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thu, Dec 15, 2011 at 05:32:47AM -0700, Samuel J. Greear wrote: Well, the only way it's going to get fixed is if someone sits down, replicates it, and starts to document exactly what it is that these benchmarks are/aren't doing. I think you will find that investigation is largely a waste of time, because not only are some of these benchmarks just downright silly, there are huge differences in the environments (compiler versions), etc., etc. leading to a largely apples/oranges comparison. But also the the analysis and reporting of the results by Phoronix is simply moronic to the point of being worse than useful, they are spreading misinformation. Take the first test as an example, Blogbench read. This doesn't raise any red flags, right? At least not until you realize that Blogbench isn't a read test, it's a read/write test. So what they have done here is run a read/write test and then thrown away the write results for both platforms and reported only the read results. If you dig down into the actual results, http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will see two Blogbench numbers, one for read and another for write. These were both taken from the same Blogbench run, so FreeBSD optimizes writes over reads, that's probably a good thing for your data but a bad thing when someone totally misrepresents benchmark results. Other benchmarks in the Phoronix suite and their representations are similarly flawed, _ALL_ of these results should be ignored and no time should be wasted by any FreeBSD committer further evaluating this garbage. (Yes, I have been down this rabbit hole). For sake of argument, let's say we throw out the Phoronix benchmarks as a data source (I don't think the benchmark specifically implied or stated this is all because of SCHED_ULE though; remember, that's what we're supposed to be focusing on. There may not be a direct correlation between the Phoronix benchmarks and the ULE issue reported here...). That said: thrown out, data ignored, done. Now what? Where are we? We're right back where we were a day or two ago; meaning no closer to solving the dilemma reported by users and SCHED_ULE. Heck, we're not even sure if there is an issue, other than some folks confirming that SCHED_4BSD performs better for them (that's what started this whole thread), and there are at least a couple which have stated this. So given the above semi-devil's-advocate response -- Sam, do you have something positive or progressive to offer so we can move forward on the ULE vs. 4BSD debacle? :-) The smiley is meant to be sincere, not sarcastic. I'm getting to the point where I'm considering formulating a private mail to Jeff Roberson, requesting that he be aware of the discussion that's happening (not that he necessarily follow or read it), and that based on what I can tell we're at a roadblock -- nobody so far is absolutely certain how to benchmark and compare ULE vs. 4BSD in multiple ways, so that those of us involved here can run such utilities and provide the data somewhere central for devs to review. I only mention this because so far I haven't seen anyone really say okay, this is what we should be using for these kinds of tests. Yay nature of the beast. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/15/2011 08:26 AM, Sergey Matveychuk wrote: 15.12.2011 17:36, Michael Larabel пишет: On 12/15/2011 07:25 AM, Stefan Esser wrote: Am 15.12.2011 11:10, schrieb Michael Larabel: No, the same hardware was used for each OS. In terms of the software, the stock software stack for each OS was used. Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with journaling enabled) should be an obvious choice since it is more similar in concept to ext4 and since that is what most FreeBSD users will use with FreeBSD? I was running some ZFS vs. UFS tests as well and this happened to have ZFS on when I was running some other tests. Can we look at the tests? My opinion is ZFS without tuning is much slower than UFS2. http://www.phoronix.com/scan.php?page=news_itempx=MTAyNjg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thu, 15 Dec 2011, Pieter de Goeje spaketh thusly: -}Detailed results here: -}http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 LOL! Pretty much 2 entirely different systems, even running different screen resolutions. Tnx for this link. -} -}As usual, the phoronix benchmarks are very misleading. Also, they tested fbsd RC2. This same thing has come up repeatedly. Seems to me big waves happened when fbsd 8.0 was coming out and phoronix tested RC1 or RC2. Unless my memory is in error (and it may well be), on the 8.0 comparison fiasco, it was pointed out that testing a fbsd RC release is like racing but being preventing from going full throttle. There are debugging hooks and various extra code bits that slow things down and are not taken out until the stable release. They *can* be taken out by the end-SA, but phoronix stated they used a stock kernel. That phoronix did this again makes me wonder... I have to agree with and cannot stress enough the importance of testing in the environment it is to be run in, with the software that is to be run on it. I used to be a massive linux fan, right up until the day I put freebsd up against several *nix boxen (IIRC Redhat, Debian, SuSE and IRIX) in a particular application I was re-working. I had to run the test several times, the difference was so great. Fbsd didn't just beat the others, it rolled 'em, smoked 'em and tapped them in the ashtray. But this was with _our_ hardware configurations and _our_ software configurations and tweaks. Currently we have a mixture of linux and fbsd in production and test. Some of the things we do run better on linux, some run better on fbsd. And if they're close, I'll pick fbsd mostly for personal reasons, e.g. it just makes more sense to me, some things I like to do are more easily done in fbsd, ... FWIW, YMMV, yadda yadda. ; -- Randy(schu...@earlham.edu) 765.983.1283 * nosce te ipsum ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Well, the only way it's going to get fixed is if someone sits down, replicates it, and starts to document exactly what it is that these benchmarks are/aren't doing. I think you will find that investigation is largely a waste of time, because not only are some of these benchmarks just downright silly, there are huge differences in the environments (compiler versions), etc., etc. leading to a largely apples/oranges comparison. But also the the analysis and reporting of the results by Phoronix is simply moronic to the point of being worse than useful, they are spreading misinformation. Take the first test as an example, Blogbench read. This doesn't raise any red flags, right? At least not until you realize that Blogbench isn't a read test, it's a read/write test. So what they have done here is run a read/write test and then thrown away the write results for both platforms and reported only the read results. If you dig down into the actual results, http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will see two Blogbench numbers, one for read and another for write. These were both taken from the same Blogbench run, so FreeBSD optimizes writes over reads, that's probably a good thing for your data but a bad thing when someone totally misrepresents benchmark results. Other benchmarks in the Phoronix suite and their representations are similarly flawed, _ALL_ of these results should be ignored and no time should be wasted by any FreeBSD committer further evaluating this garbage. (Yes, I have been down this rabbit hole). Best, Sam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/15/2011 07:25 AM, Stefan Esser wrote: Am 15.12.2011 11:10, schrieb Michael Larabel: No, the same hardware was used for each OS. In terms of the software, the stock software stack for each OS was used. Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with journaling enabled) should be an obvious choice since it is more similar in concept to ext4 and since that is what most FreeBSD users will use with FreeBSD? I was running some ZFS vs. UFS tests as well and this happened to have ZFS on when I was running some other tests. Did you tune the ZFS ARC (e.g. vfs.zfs.arc_max=6G) for the tests? The OS was left in its stock configuration. And BTW: Did your measured run times account for the effect, that Linux keeps much more dirty data in the buffer cache (FreeBSD has a low limit on dirty buffers since under realistic load the already cached data is much more likely to be reused and thus more valuable than freshly written data; aggressively caching dirty data would significantly reduce throughput and responsiveness under high load). Given the hardware specs of the test system, I guess that Linux accepts at least 100 times the dirty data in the buffer cache, compared to FreeBSD (where this number is at most in the tens of megabyte range). If you did not, then your results do not represent a server load (which I'd expect relevant, if you are testing against Oracle Linux 6.1 server), where continuous performance is required. Tests that run on an idle system starting in a clean state and ignoring background flushing of the buffer cache after the timed program has stopped are perhaps useful for a very lowly loaded PC, but not for a system with high load average as the default. I bet that if you compared the systems under higher load (which admittedly makes it much harder to get sensible numbers for the program under test) or with reduced buffer cache size (or raise the dirty buffer limit in FreeBSD accordingly, which ought to be possible with sysctl and/or boot time tuneables, e.g. vfs.hidirtybuffers). And a last remark: Single benchmark runs do not provide reliable data. FreeBSD comes with ministat to check the significance of benchmark results. Each test should be repeated at least 5 times for meaningful averages with acceptable confidence level. The Phoronix Test Suite runs most tests a minimum of three times and if the standard deviation exceeds 3.5% the run count is dynamically increased, among other safeguards. -- Michael Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
2011/12/13 Jeremy Chadwick free...@jdc.parodius.com:
On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
Not fully right, boinc defaults to run on idprio 31 so this isn't an
issue. And yes, there are cases where SCHED_ULE shows much better
performance then SCHED_4BSD. ??[...]
Do we have any proof at hand for such cases where SCHED_ULE performs
much better than SCHED_4BSD? Whenever the subject comes up, it is
mentioned, that SCHED_ULE has better performance on boxes with a ncpu
2. But in the end I see here contradictionary statements. People
complain about poor performance (especially in scientific environments),
and other give contra not being the case.
Within our department, we developed a highly scalable code for planetary
science purposes on imagery. It utilizes present GPUs via OpenCL if
present. Otherwise it grabs as many cores as it can.
By the end of this year I'll get a new desktop box based on Intels new
Sandy Bridge-E architecture with plenty of memory. If the colleague who
developed the code is willing performing some benchmarks on the same
hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
recent Suse. For FreeBSD I intent also to look for performance with both
different schedulers available.
This is in no way shape or form the same kind of benchmark as what
you're planning to do, but I thought I'd throw it out there for folks to
take in as they see fit.
I know folks were focused mainly on buildworld.
I personally would find it interesting if someone with a higher-end
system (e.g. 2 physical CPUs, with 6 or 8 cores per CPU) was to do the
same test (changing -jX to -j{numofcores} of course).
--
| Jeremy Chadwick ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??jdc at
parodius.com |
| Parodius Networking ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
http://www.parodius.com/ |
| UNIX Systems Administrator ?? ?? ?? ?? ?? ?? ?? ?? ?? Mountain View, CA,
US |
| Making life hard for others since 1977. ?? ?? ?? ?? ?? ?? ?? PGP 4BD6C0CB
|
sched_ule
===
- time make -j2 buildworld
??1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io 4565pf+0w
- time make -j2 buildkernel
??640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w
sched_4bsd
- time make -j2 buildworld
??1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io 6451pf+0w
- time make -j2 buildkernel
??638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w
software
==
* sched_ule test: ??FreeBSD 8.2-STABLE, Thu Dec ??1 04:37:29 PST 2011
* sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST 2011
Hi Jeremy,
thanks for the time you spent on this.
However, I wanted to ask/let you note 3 things:
1) Did you use 2 different code base for the test? (one updated on
December 1 and another one on December 12)
No; src-all (/usr/src on this system) was not updated between December
1st and December 12th PST. I do believe I updated it today (15th PST).
I can/will obviously hold off so that we have a consistent code base for
comparing numbers between schedulers during buildworld and/or
buildkernel.
2) Please note that you should have repeated this test several times
(basically until you don't get a standard deviation which is
acceptable with ministat) and report the ministat output
This is the first time I have heard of ministat(1). I'm pretty sure I
see what it's for and how it applies to this situation, but boy that man
page could use some clarification (I have 3 people looking at this thing
right now trying to figure out what means what in the graph :-) ).
Anyway, graph or not, I see the point.
Regarding multiple tests: yup, you're absolutely right, the only way to
do it would be to run a sequence of tests repeatedly (probably 10 per
scheduler). Reboots and rm -fr /usr/obj/* would be required after each
test too, to guarantee empty kernel caches (of all types) consistently
every time.
What I posted was supposed to give people just a general idea if there
was any gigantic difference between the two, and there really isn't.
But, as others have stated (and you below), buildworld may not be an
effective way to benchmark what we're trying to test.
Hence me wondering exactly what would make for a good test. Example:
1. Run + background some program that beats on things (I really don't
know what; creation/deletion of threads? CPU benchmark? bonnie++?),
with output going to /dev/null.
2. Run + background time make -j2 buildworld with output going to /dev/null
3. Record/save output from time.
4. rm -fr /usr/obj shutdown -r now
5. Repeat all steps ~10 times
6. Adjust kernel configuration file to use other scheduler
7. Repeat steps 1-5.
What I'm trying to figure out is what #1 and #2 should be in the above
example.
3) The difference is less than 2% which I suspect is really
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Thanks. My request for the person documenting the tunings also runs = the benchmark to ensure expected behaviour. The installation, execut= ion and comparison against the benchmarks in the article is fairly simple.= br Note that some tuning may not be relevant or recommended (ie: some o f the fs benchmarks are sensitive to barriers and other synchronous operati= ons). I'd recommend bowing out of a benchmark with a 'we're going to = be slower since the default configuration is this way for the following rea= son' if this is the case. Thanks 'someone'. Matthew Dec 16, 2011 8:46 AM,= Adrian Chadd adr...@freebsd.org wrote: Can someone please write up a nice, concise blog post somewhere outlining all of this? Extra bonus points if it's a blog t= hat is picked up by blogs.freebsdish.org and/or some of the other BSD= sites. Guys/girls/fuzzy things - this is 2011; people look at= shiny blog sites with graphs rather than mailing lists. Sorry, we lo= st that battle. :) Adrian __= _ freebsd-performa...@freebsd.org= mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-perfo= rmance To unsubscribe, send any mail to freebsd-performance-unsubscr i...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: On 13/12/2011 09:00, Andrey Chernov wrote: I observe ULE interactivity slowness even on single core machine (Pentium 4) in very visible places, like 'ps ax' output stucks in the middle by ~1 second. When I switch back to SHED_4BSD, all slowness is gone. I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine with 16 logical CPUs. If I run tar xf somefile.tar and make -j16 buildworld then logging into another console can take several seconds. Sometimes even the Password: prompt can take a couple of seconds to appear after typing my username. I'd resigned myself to expecting this sort of behaviour as 'normal' on my single core 1133MHz PIII-M. As a reproducable data point, running 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat the CPU while testing my manual fan control script, hogs it up pretty much while regularly running the script below in another konsole to check values - which often gets stuck half way, occasionally pausing _twice_ before finishing. Switching back to the first konsole (on another desktop) to kill the dd can also take a couple/few seconds. t23# cat /root/bin/t23stat #!/bin/sh echo -n `date` sysctl dev.cpu.0.freq dev.cpu.0.cx_usage sysctl dev.acpi_ibm | egrep 'fan_|thermal' sysctl hw.acpi.thermal.tz0.temperature acpiconf -i0 | egrep 'State|Remain|Present|Volt' Sure it's a slow machine, but it normally runs pretty smoothly. Anything with a bit of disk i/o, like buildworld, runs smooth as. This is on 8.2-R GENERIC, HZ=1000, 768MB with lots free, no swap in use. I'll definitely be trying SCHED_4BSD after updating to 8-stable unless a 'miracle cure' appears beforehand. cheers, Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SCHED_ULE should not be the default
The trouble is that there's lots of anecdotal evidence, but noone's really gone digging deep into _their_ example of why it's broken. The developers who know this stuff don't see anything wrong. That hints to me it may be something a little more creepy - as an example, the interplay between netisr/swi/taskqueue/callbacks and such. It may be that something is being starved that isn't obviously obvious. It's just a stab in the dark, but it sounds somewhat plausible based on what I've seen ULE do in my network throughput hacking. I applaud reppie for trying to make it as easy as possible for people to use KTR to provide scheduler traces for him to go digging with, so please, if you have these issues and you can absolutely reproduce them, please follow his instructions and work with him to get him what he needs. Adrian (wow, lots of personal pronouns packed into one sentence. It must be sleep time.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: openpam oddity?
Michael Butler i...@protected-networks.net writes: Any ideas why courier-authdaemon is now reporting .. authdaemond: in openpam_dynamic(): No error: 0 authdaemond: in openpam_load_module(): no pam_unix.so found I've recompiled libpam and courier from scratch :-( Can you ktrace courier-authdaemon? # env LD_UTRACE /usr/local/etc/rc.d/courier-authdaemond restart # ktrace -di -tcntu -p $(cat /var/run/authdaemond/pid) then reproduce the error, then # /usr/local/etc/rc.d/courier-authdaemond restart to stop the trace, and # kdump courier-authdaemond-trace.txt to translate it to human-readable form. The trace will *not* include any passwords, just a list of system calls, filename lookups and linker operations. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on sparc64/sparc64
On 18. Dec 2011, at 18:07 , Dag-Erling Smørgrav wrote: FreeBSD Tinderbox tinder...@freebsd.org writes: In file included from /src/sys/dev/e1000/if_em.c:400: /src/sys/dev/netmap/if_em_netmap.h: In function 'em_netmap_rxsync': /src/sys/dev/netmap/if_em_netmap.h:332: warning: dereferencing 'void *' pointer /src/sys/dev/netmap/if_em_netmap.h:332: error: request for member 'dt_mt' in something not a structure or union *** Error code 1 I made a mistake when I added support for additional LINT kernels (e.g. LINT-NOINET) so the additional kernels got built, but plain LINT didn't. As a result, this error has gone unnoticed by the tinderbox, even though it's been there for quite a while (or so I've been told). Thanks a lot for fixing the tinderbox (I remember I had seen the original expression and had missed that LINT case). On the error: I have seen it for at least 4 days but hadn't removed my obj tree entirely. I also followed up to one of the later commits with jfv and luigi discussing the last driver update, so hope they'll fix it soon. Thanks a lot again for promptly fixing the script and compiling LINT again as well! /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
