Re: Clang as default compiler November 4th
On 2012-Sep-11, 23:29, Doug Barton wrote: What we need to do is what I and others have been asking to do for years. We need to designate a modern version of gcc (no less than 4.6) as the official default ports compiler, and rework whatever is needed to support this. Fortunately, that goal is much more easily achieved than fixing ports to build and run with clang. (It's harder than it sounds because there are certain key libs that define some paths depending on what compiler they were built with, but still easier than dealing with clang in the short term.) I like the idea very much. My only concern is that gcc is heavy to build. I can't imagine booting into a freshly installed production machine and having to install gcc just to build the couple of ports that I need there. Unless we provide a fast shortcut way to have make depends install gcc via pkg when needed, or some similar mechanism.. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpnuCIUIWf4L.pgp Description: PGP signature
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 08:21:31AM +0200, Pietro Cerutti wrote: On 2012-Sep-11, 23:29, Doug Barton wrote: What we need to do is what I and others have been asking to do for years. We need to designate a modern version of gcc (no less than 4.6) as the official default ports compiler, and rework whatever is needed to support this. Fortunately, that goal is much more easily achieved than fixing ports to build and run with clang. (It's harder than it sounds because there are certain key libs that define some paths depending on what compiler they were built with, but still easier than dealing with clang in the short term.) I like the idea very much. My only concern is that gcc is heavy to build. Gerald has been advocating this for a while as well. In fact, he's just made a commit that makes the lang/gcc42 compiler much easier to bootstrap itself. There's a set of interlocking changes that we need to make to the infrastructure to modernize our compiler choices. I've been talking to Gerald about some of the aspects of it and hope to have something to propose fairly soon. But IMHO it's a little bit trickier than it appears at first glance. mcl ___ 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: Building world with clang ToT
Hi Brook, On 12-09-12 18:34, Brooks Davis wrote: snip Note that some people have been working on external toolchain support. This would aim to make it possible to do what you were trying, e.g. building world using WITHOUT_TOOLCHAIN, which sets both WITHOUT_CLANG and WITHOUT_GCC, among others. However, I am not sure how far these efforts have come by now. :-) I've got some patches that aren't quite ready for prime-time that allow me to cross build world with an external CLANG. I'll post them to the toolchain@ list when they are closer to ready (hopefully quite soon). -- Brooks I'd be interested in those, even if there are some rough edges. (I don't mind sub-prime, this time ;) FWIW: The clang build finished too, but with two hick-ups: 1. - kdump: build reports 4 errors: === usr.bin/kdump (depend) sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mksubr /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include kdump_subr.c env MACHINE=amd64 CPP=cpp sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mkioctls print /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include ioctl.c stdin:8:31: error: cam/scsi/scsi_enc.h: No such file or directory stdin:17:33: error: dev/filemon/filemon.h: No such file or directory stdin:35:33: error: fs/nandfs/nandfs_fs.h: No such file or directory stdin:46:24: error: net/netmap.h: No such file or directory (As a consequence ?) clang doesn't pick up 2 symbols: MFI_CMD32 and MFIIO_PASSTHRU32 which are defined if COMPAT_FREEBSD32 is set in sys/dev/mfi/mfi_ioctl.h 2. lint calls tmp/usr/cc directly: buildworld-clang.log:=== usr.bin/xlint/llib (all) buildworld-clang.log:lint -cghapbx -Cposix /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib/llib-lposix buildworld-clang.log:lint: cannot exec /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/bin/cc: No such file or directory buildworld-clang.log:Stop in /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib. A link from cc to clang in the same directory fixes that. Regards, Ed. ps: re. 1: the gcc build calls: === usr.bin/kdump (depend) /bin/sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/../../sys/kern/makesyscalls.sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/../../sys/amd64/linux32/syscalls.master /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/linux_syscalls.conf sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mksubr /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include | sed -n 's/^\([a-z].*)\)$/void \1;/p' kdump_subr.h echo int nlinux_syscalls = sizeof(linux_syscallnames) / sizeof(linux_syscallnames[0]); linux_syscalls.c env MACHINE=amd64 CPP=cpp sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mkioctls print /usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include ioctl.c ___ 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: Building world with clang ToT
On 2012-09-13 11:27, Edward Meewis wrote:
...
FWIW: The clang build finished too, but with two hick-ups:
1. - kdump: build reports 4 errors:
=== usr.bin/kdump (depend)
sh /usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mksubr
/usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include kdump_subr.c
env MACHINE=amd64 CPP=cpp sh
/usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/kdump/mkioctls print
/usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/include ioctl.c
stdin:8:31: error: cam/scsi/scsi_enc.h: No such file or directory
stdin:17:33: error: dev/filemon/filemon.h: No such file or directory
stdin:35:33: error: fs/nandfs/nandfs_fs.h: No such file or directory
stdin:46:24: error: net/netmap.h: No such file or directory
(As a consequence ?) clang doesn't pick up 2 symbols: MFI_CMD32 and
MFIIO_PASSTHRU32 which are defined if COMPAT_FREEBSD32 is set in
sys/dev/mfi/mfi_ioctl.h
I don't think this has anything to do with clang, since you can see
CPP=cpp in that command line, which usually is GNU cpp. For clang,
you should set CPP=clang-cpp instead.
What seems to be happening is that certain headers it expects are not
install in ${DESTDIR}, which should be ${WORLDTMP} during buildworld.
It is possible that due to all the WITHOUT_ options you have defined,
some of those headers may not be installed.
2. lint calls tmp/usr/cc directly:
buildworld-clang.log:=== usr.bin/xlint/llib (all)
buildworld-clang.log:lint -cghapbx -Cposix
/usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib/llib-lposix
buildworld-clang.log:lint: cannot exec
/usr/obj/usr/home/emeewis/contrib/FreeBSD-HEAD/tmp/usr/bin/cc: No such
file or directory
buildworld-clang.log:Stop in
/usr/home/emeewis/contrib/FreeBSD-HEAD/usr.bin/xlint/llib.
A link from cc to clang in the same directory fixes that.
Yes, that is a known problem in lint, but I have no great urge to fix
it. IMHO lint should be axed, the program is simply obsolete.
___
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: Clang as default compiler November 4th
On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote: In regards to my initial post in this thread, I was just trying to assess whether any benchmarks have been performed on FreeBSD for floating point generated by clang. Other than the limited testing that I've done, it appears that the answer is 'no'. We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I know nothing about the former (just noticed it for the first time). The latter I think is a set of correctness tests rather than performance tests. -- 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: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote: On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote: In regards to my initial post in this thread, I was just trying to assess whether any benchmarks have been performed on FreeBSD for floating point generated by clang. Other than the limited testing that I've done, it appears that the answer is 'no'. We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I know nothing about the former (just noticed it for the first time). The latter I think is a set of correctness tests rather than performance tests. It's quite clear that the clang proponent have not tried to run src/tools/regression/lib/msun. % setenv CC clang % make | grep warning | wc -l 1354 % make clean % make | tee make.log % head -20 make.log clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESSON ^ test-cexp.c:183:2: warning: expression result unused [-Wunused-value] testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); ^~~ test-cexp.c:98:7: note: expanded from macro 'testall' test(cexp, x, result, exceptmask, excepts, checksign); \ ^ test-cexp.c:87:11: note: expanded from macro 'test' assert(((func), fetestexcept(exceptmask) == (excepts)));\ ^ /usr/include/assert.h:54:21: note: expanded from macro 'assert' #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ ^ test-cexp.c:183:2: warning: expression result unused [-Wunused-value] testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); ^~~ test-cexp.c:99:7: note: expanded from macro 'testall' % tail -20 make.log test-trig.c:69:11: note: expanded from macro 'test' assert(((func), fetestexcept(exceptmask) == (excepts)));\ ^ /usr/include/assert.h:54:21: note: expanded from macro 'assert' #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ ^ 74 warnings generated. clang -O2 -pipe -march=opteron -O0 -lm test-fenv.c -o test-fenv test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON ^ 1 warning generated. for p in test-cexp test-conj test-csqrt test-ctrig test-exponential test-fma test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint test-lround test-nan test-nearbyint test-next test-rem test-trig test-fenv; do /usr/src/tools/regression/lib/msun/$p; done Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) == (0))), function test_nan, file test-cexp.c, line 211. 1..7 ok 1 - cexp zero Abort trap (core dumped) *** [tests] Error code 134 Stop in /usr/src/tools/regression/lib/msun. So, clang does not support #pragma STDC FENV_ACCESS ON. That (IMHO) is a show stopper for clang as the default compiler, because at least msun/src/e_sqrtl.c uses this pragma. -- Steve ___ 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: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESSON [...] So, clang does not support #pragma STDC FENV_ACCESS ON. That (IMHO) is a show stopper for clang as the default compiler, because at least msun/src/e_sqrtl.c uses this pragma. Neither does gcc, AFAIK (http://gcc.gnu.org/c99status.html). It just silently ignores the pragma. 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: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 06:25:37PM +0200, Stefan Farfeleder wrote: On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESSON [...] So, clang does not support #pragma STDC FENV_ACCESS ON. That (IMHO) is a show stopper for clang as the default compiler, because at least msun/src/e_sqrtl.c uses this pragma. Neither does gcc, AFAIK (http://gcc.gnu.org/c99status.html). It just silently ignores the pragma. Hmmm, indeed, you are correct. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 I seems to have mis-remembered a patch that went into newer gcc. -- Steve ___ 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: mfi driver performance
On 09/10/12 19:31, Garrett Cooper wrote: On Mon, Sep 10, 2012 at 7:15 PM, matt sendtom...@gmail.com wrote: ... mfip was necessary, and allowed smartctl to work with '-d sat' bonnie++ comparison. Run with no options immediately after system boot. In both cases the same disks are used, two Seagate Barracuda 1TB 3G/S (twin platter) and a Barracuda 500G 3G/s (single platter) in a zfs triple mirror that the system was booted from. All are 7200 RPM drives with 32mb cache, and mediocre performance compared to my hitachi 7k3000s or the 15k sas cheetahs at work etc. Firmwares were the latest 2108it vs the latest imr_fw that work on the 9240/9220/m1015/drake skinny. I wish I had some 6g ssds to try! MPS: Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 122 99 71588 24 53293 20 284 90 222157 33 252.6 49 Latency 542ms 356ms 914ms 991ms 337ms 271ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 22197 93 9367 27 16821 99 23555 99 + +++ 23717 99 Latency 31650us 290ms 869us 23036us 66us 131us 1.96,1.96,flatline.local,1,1347322810,32G,,122,99,71588,24,53293,20,284,90,222157,33,252.6,49,16,22197,93,9367,27,16821,99,23555,99,+,+++,23717,99,542ms,356ms,914ms,991ms,337ms,271ms,31650us,290ms,869us,23036us,66us,131us MFI: Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 125 99 71443 24 53177 21 317 99 220280 33 255.3 52 Latency 533ms 566ms 1134ms 86565us 357ms 252ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 22347 94 12389 30 16804 100 18729 99 27798 99 5317 99 Latency 33818us 233ms 558us 26581us 75us 12319us 1.96,1.96,flatline.local,1,1347329123,32G,,125,99,71443,24,53177,21,317,99,220280,33,255.3,52,16,22347,94,12389,30,16804,100,18729,99,27798,99,5317,99,533ms,566ms,1134ms,86565us,357ms,252ms,33818us,233ms,558us,26581us,75us,12319us A close race, with some wins for each. Latency on sequential input and deleted files per second appear to be interesting salients. A lot of the other stuff is back and forth and probably not statistically significant (although not much of a sample set :) ). I tried to control as many variables as possible, but obviously it's one controller in one configuration, Your Mileage May Vary. Try upping the queue depth (hw.mfi.max_cmds); this is controller dependent. Cheers, -Garrett It seems hw.mfi.max_cmds is read only. The performance is pretty close to expected with no nvram or bbu on this card and commodity disks from 1.5 years ago, as far as I'm concerned. I'd love better write performance, but it's probably being held back by the single platter in the mirror when it is writing far from its edge. Is there any way to check the interface speed with an mfisyspd? When I added mfip to my kernel config, the pass devices are all reporting 150MB/S which is incorrect. Matt ___ 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: mfi driver performance
On Thu, Sep 13, 2012 at 12:54 PM, matt sendtom...@gmail.com wrote: On 09/10/12 19:31, Garrett Cooper wrote: ... It seems hw.mfi.max_cmds is read only. The performance is pretty close to expected with no nvram or bbu on this card and commodity disks from 1.5 years ago, as far as I'm concerned. I'd love better write performance, but it's probably being held back by the single platter in the mirror when it is writing far from its edge. Try loader.conf: $ grep -r hw.mfi.max_cmds /sys/dev/mfi/ /sys/dev/mfi/mfi.c:TUNABLE_INT(hw.mfi.max_cmds, mfi_max_cmds); Cheers, -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: mfi driver performance
On 09/13/12 13:13, Garrett Cooper wrote: On Thu, Sep 13, 2012 at 12:54 PM, matt sendtom...@gmail.com wrote: On 09/10/12 19:31, Garrett Cooper wrote: ... It seems hw.mfi.max_cmds is read only. The performance is pretty close to expected with no nvram or bbu on this card and commodity disks from 1.5 years ago, as far as I'm concerned. I'd love better write performance, but it's probably being held back by the single platter in the mirror when it is writing far from its edge. Try loader.conf: $ grep -r hw.mfi.max_cmds /sys/dev/mfi/ /sys/dev/mfi/mfi.c:TUNABLE_INT(hw.mfi.max_cmds, mfi_max_cmds); Cheers, -Garrett $ cat /usr/src/sys/dev/mfi/*.c | fgrep 'max_cmds' static intmfi_max_cmds = 128; TUNABLE_INT(hw.mfi.max_cmds, mfi_max_cmds); SYSCTL_INT(_hw_mfi, OID_AUTO, max_cmds, CTLFLAG_RD, mfi_max_cmds, ncmds = MIN(mfi_max_cmds, sc-mfi_max_fw_cmds); Definitely a loader tunable, thanks. I'll try increasing and decreasing the value and running bonnie again...Still not sure whether I'm getting 3gb/s and 6gb/s negotiation with my drives. MPS correctly reported da devices with 600mb/s and 300mb/s transfers where appropriate. mfiutil doesn't seem to know, and mfip devices appear as 150mb/s. No transfer speed message when mfisyspd devices attach. Matt ___ 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: mfi driver performance
On 09/13/12 13:13, Garrett Cooper wrote: On Thu, Sep 13, 2012 at 12:54 PM, matt sendtom...@gmail.com wrote: On 09/10/12 19:31, Garrett Cooper wrote: ... It seems hw.mfi.max_cmds is read only. The performance is pretty close to expected with no nvram or bbu on this card and commodity disks from 1.5 years ago, as far as I'm concerned. I'd love better write performance, but it's probably being held back by the single platter in the mirror when it is writing far from its edge. Try loader.conf: $ grep -r hw.mfi.max_cmds /sys/dev/mfi/ /sys/dev/mfi/mfi.c:TUNABLE_INT(hw.mfi.max_cmds, mfi_max_cmds); Cheers, -Garrett Here are the results for differing values of max_cmds with same test conditions as against mps Original mfi performance (max_cmds=128) Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 125 99 71443 24 53177 21 317 99 220280 33 255.3 52 Latency 533ms 566ms1134ms 86565us 357ms 252ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 22347 94 12389 30 16804 100 18729 99 27798 99 5317 99 Latency 33818us 233ms 558us 26581us 75us 12319us 1.96,1.96,flatline.local,1,1347329123,32G,,125,99,71443,24,53177,21,317,99,220280,33,255.3,52,16,22347,94,12389,30,16804,100,18729,99,27798,99,5317,99,533ms,566ms,1134ms,86565us,357ms,252ms,33818us,233ms,558us,26581us,75us,12319us max_cmds=256 Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 125 99 70856 24 53503 21 327 98 232650 33 265.1 60 Latency 637ms 522ms1050ms 121ms 318ms 339ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 17126 76 11865 31 17134 99 18265 99 27169 100 5006 99 Latency 114ms 522ms 875us 24250us 87us 14324us 1.96,1.96,flatline.local,1,1347580235,32G,,125,99,70856,24,53503,21,327,98,232650,33,265.1,60,16,17126,76,11865,31,17134,99,18265,99,27169,100,5006,99,637ms,522ms,1050ms,121ms,318ms,339ms,114ms,522ms,875us,24250us,87us,14324us max_cmds=64 Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP flatline.local 32G 125 99 71161 24 54035 21 288 90 229860 34 254.2 62 Latency 310ms 378ms 809ms 567ms 308ms 447ms Version 1.96 --Sequential Create-- Random Create flatline.local -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 22570 95 14243 35 13170 99 23503 99 + +++ 5 99 Latency 18111us 282ms1165us 24786us 117us 80us 1.96,1.96,flatline.local,1,1347584224,32G,,125,99,71161,24,54035,21,288,90,229860,34,254.2,62,16,22570,95,14243,35,13170,99,23503,99,+,+++,5,99,310ms,378ms,809ms,567ms,308ms,447ms,18111us,282ms,1165us,24786us,117us,80us Still digesting the differences, but 256 seems to get more random seeks and better sequential reads at the expense of higher latencies (some probably identical). I think with lots of small files like a buildworld, it looks like 64 would excel slightly more than 128, but the differences between 128 and 64 are less extreme than the difference between 128 and 256. Interestingly, sequential read appears better at 64 and 256 than 128, but I assume this is a testing fluke...sample set is small. Matt ___ 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
Call for bge(4) testers
All, There were lots of reports that stock bge(4) does not work on Dell Rx20/HP DL 360 G8. With the help of Broadcom and BCM5719/BCM5720 users I managed to address the issue but I had to touch very sensitive part of driver. Before committing the change to tree I'd like to know whether this change introduces regressions on old bge(4) controllers. If you're bge(4) user, please try latest WIP version at the following URL and let me know how it goes on your box. I'm especially interested in whether there is any ASF/IPMI regression on BCM570x/571x. http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h http://people.freebsd.org/~yongari/bge/brgphy.c Build instructions 1. Copy both if_bge.c/if_bgereg.h to /usr/src/sys/dev/bge directory 2. Copy brgphy.c /usr/src/sys/dev/mii 3. Rebuild kernel and reboot to take the change effect. You can also use the files above for for 9.1/stable/9. For stable/8 it needs slight modification and I couldn't find time to regenerate the patch. Thanks. ___ 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
