Re: clang (__builtin_ffs) vs /usr/include/string.h
Lsof.. And this seems like a contradiction between the string.h declaration and the built-in one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Benjamin Kaduk ka...@mit.edu wrote: Hi Larry, On Tue, 20 Dec 2011, Larry Rosenman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is anyone going to fix the following in the clang or FreeBSD system? I haven't seen any mention of __builtin_ffs on any freebsd lists since your thread in october, system headers with clang?. That rather makes me suspect that no one else is seeing this problem. It's hard to fix something you don't know about. In file included from /usr/include/string.h:45: /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' int ffs(int) __pure2; ^ /usr/include/machine/cpufunc.h:140:24: note: expanded from: #define ffs(x) __builtin_ffs(x) ^ /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int (unsigned int)' 7 warnings and 1 error generated. *** Error code 1 As such, since we don't know what the problem is, some context for what is going on here would be useful -- what are you trying to compile? Still lsof? This looks like something that needs to change in clang/FreeBSD headers. Not necessarily -- things from the machine/ hierarchy are pretty uncommon, and I wouldn't be surprised if they had dependencies and ordering requirements involved. It could well be an application error, but we can't tell, since there is no context. -Ben Kaduk ___ 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 (__builtin_ffs) vs /usr/include/string.h
on 21/12/2011 11:31 Larry Rosenman said the following: Lsof.. And this seems like a contradiction between the string.h declaration and the built-in one. It more looks like you include machine/cpufunc.h before strings.h and that has an undesired side effect. -- Andriy Gapon ___ 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: Is the svn2cvs gateway down ?
On 21. Dec 2011, at 02:23 , Doug Barton wrote: On 12/20/2011 02:01, Claude Buisson wrote: Hi, It seems (from my own csup's and cvswe.cgi) that the src commits are lost, starting with r228697 Sun Dec 18 22:04:55 2011) Yeah, my warning 2 days ago that this was going to happen seems to have gone un-heeded. :) I'm sure you can take bz' word that it's being looked at now though. It's been fixed and the changes should propagate to cvsup mirrors close to everyone the next two hours. /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
Re: a few usb issues related to edge cases
on 20/12/2011 14:25 Andriy Gapon said the following: I just wanted to draw your attention to the fact that obtaining any locks in the kdb context (or USB polling code in general, even) is not a good idea. Chances of getting into trouble on those locks are probably quite moderate or even low, but they do exist. I am not sure if you are getting any bug reports about such troubles :-) Regular users probably do not use kdb too often and a panic for them is just a crash, so they likely do not expect anything usable/debuggable after that :-) Looking some more at the code I just got myself confused as to how the dumping to a umass device could work when the scheduler is stopped. It seems that the umass_command_start - usbd_transfer_start - usbd_callback_ss_done_defer functions would always put a transfer request onto a queue and try to wake up a thread to process that queue and the request. But that's obviously not going to work when the other thread is not going to be run. Have I missed a code path that leads directly to the controller in this context? Thank you for your help. -- Andriy Gapon ___ 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
REMAINDER: Call for FreeBSD Status Reports - 4Q/2011
Dear all, I would like to remind you that the next round of status reports covering the fourth quarter of 2011 are due on January 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports as sooner than later (holidays are quickly approaching), so that we can compile the report in a timely fashion. Do not hesitate and write a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome as well. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo ___ 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 Tue, Dec 20, 2011 at 03:29:25PM -0800, Jeremy Chadwick wrote: This also interested me: * Linux system crashed http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html * OpenIndiana system crashed same way as Linux system http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00017.html I cannot help but wonder if the Linux and OpenIndiana installations were more stressful on the hardware -- getting more out of the system, maybe resulting in increased power/load, which in turn resulted in the systems locking up (shoddy PSU, unstable mainboard, MCH problems, etc.). My point is that Francois states these things in such a way to imply that DragonflyBSD was more stable, Same thing can be said for FreeBSD, only Linux and OpenIndiana crashed reliably if I remember correctly. when in fact I happen to wonder the opposite point -- that is to say, Linux and OpenIndiana were trying to use the hardware more-so than DragonflyBSD, thus tickled what may be a hardware-level problem. I actually ran the benchmarks on two different machines with the same hardware -- brand new Supermicro boxes with ECC memory and no cut corners. Since then, I've found I could stop the Linux crashes by disabling some options in the BIOS setup: - advanced ACPI settings (don't remember exactly which ones) - and a new WHEA one. WHEA means Windows Hardware Error Architecture. For all I know, it may have been the only culprit but I didn't have time to verify if the machines also ran fine with only this option disabled. -- Francois Tigeot ___ 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: r228700 can't dhclient em0
Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B While this is the documented path, it's not actually been required B except in edge cases for ages (the last I can remember is a.out-elf). B It's been long enough that I don't think we can really make people do B it except for a short period of time in HEAD. I believe it's B unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. I hope, this change would satisfy you, and you won't say that We almost certainly need to back r228571 out. The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions dhclient, I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 So, if we are claiming for an undocumented but important feature that new kernel being capable to configure network with world from a previous major release, then I should merge r228463 right now to stable/9, and not merge r228313. If I don't merge r228463 before 9.0-RELEASE is out, then in 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with world from 9.0-RELEASE. Thus, should I now either bribe re@ to push r228463 prior to release, either back out the bugfix: r228463. Also, backing out r228463 would require backing out a larger work: r228455. Hey, this policy greatly discourages hacking on bugs and new features... :( -- 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
21.12.2011, 04:28, O. Hartmann ohart...@zedat.fu-berlin.de: On 12/21/11 00:29, Jeremy Chadwick wrote: On Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote: On 12/20/11 22:45, Samuel J. Greear wrote: http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux and Solaris. Steps to reproduce these benchmarks provided. Sam On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky i...@hybrid-lab.co.ukwrote: Interestingly, while people seem to be (arguably rightly) focused on criticising Phoronix's benchmarking, nobody has offered an alternative benchmark; and while (again, arguably rightly) it is important to benchmark real world performance, equally, nobody has offered any numbers in relation to, for example, HTTP or SMTP, or any other real world-application torture tests done on the aforementioned two platforms... IMO, this just goes to show that doing is hard and criticising is much easier (yes, I am aware of the irony involved in making this statement, but someone has to!) Cheers, Igor M :-) ___ 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 Thanks for those numbers. Impressive how Matthew Dillon's project jumps forward now. And it is still impressive to see that the picture is still in the right place when it comes to a comparison to Linux. Also, OpenIndiana shows an impressive performance. Preface to my long post below: The things being discussed here are benchmarks, as in how much work can you get out of Thing. This is VERY DIFFERENT from testing interactivity in a scheduler, which is more of a test that says when Thing X is executed while heavier-Thing Y is also being executed, how much interaction is lost in Thing X. The reason people notice this when using Xorg is because it's visual, in an environment where responsiveness is absolutely mandatory above all else. Nobody is going to put up with a system where during a buildworld they go to move a window or click a mouse button or type a key and find that the window doesn't move, the mouse click is lost, or the key typed has gone into the bit bucket -- or, that those things are SEVERELY delayed, to the point where interactivity is crap. I whitnessed sticky, jumpy and non-responsive-for seconds FreeBSD servers (serving homes, NFS/SAMBA and PostgreSQL database (small)). Those seconds where enough to cut a ssh line. Not funny. Network traffic droped significantly. X/Desktop makes the problem visible, indeed. But not seeing it does not mean it isn't there. This might be the reason why FreeBSD is so much behind when it comes to X? Well... Are you talking about FreeBSD being laggy with the X and other GUI staff? Well, am I so lucky to have great responsiveness and interactivity here in X with the FreeBSD? The interactiveness was one the reasons I've switched my desktop from Windows to *nix (specifically FreeBSD). I just want to make that clear to folks. This immense thread has been Regards, Vans. ___ 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: extattr_set_*() return type
On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote: Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes written, shouldn't their return value be 'ssize_t' instead of 'int'? It looks like the system calls themselves already do the right thing in setting td_retval[] (they assign a ssize_t to it and td_retval[0] can hold a ssize_t on all of our current platforms). It would seem that the only change would be to the header and probably syscalls.master. I guess this would require a symver bump to fix though. An extended attribute larger than 2GB is a programming abuse, though. Technically int may not be 32 bits but it is on all supported platforms now. Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by some. :) The type should match the documented behavior. On OS X the set operation doesn't return a size but instead returns a simple success/failure (0 or -1) for which an int is appropriate. However, the FreeBSD API documents that it operates like write and consumes the buffer. Note that the size of the buffer passed to the 'set' and 'get' operations is a size_t, not an int, and the 'get' operations already return a ssize_t, not an int. -- John Baldwin ___ 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: extattr_set_*() return type
On 21 Dec 2011, at 15:31, John Baldwin wrote: On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote: Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes written, shouldn't their return value be 'ssize_t' instead of 'int'? It looks like the system calls themselves already do the right thing in setting td_retval[] (they assign a ssize_t to it and td_retval[0] can hold a ssize_t on all of our current platforms). It would seem that the only change would be to the header and probably syscalls.master. I guess this would require a symver bump to fix though. An extended attribute larger than 2GB is a programming abuse, though. Technically int may not be 32 bits but it is on all supported platforms now. Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by some. :) The type should match the documented behavior. On OS X the set operation doesn't return a size but instead returns a simple success/failure (0 or -1) for which an int is appropriate. However, the FreeBSD API documents that it operates like write and consumes the buffer. Note that the size of the buffer passed to the 'set' and 'get' operations is a size_t, not an int, and the 'get' operations already return a ssize_t, not an int. Using an int was probably a bug. If we can switch to a ssize_t without undue disruption, it seems worthwhile to do so. There was never EA API standardisation, and it might be worth pondering whether to pick up additional API variants matching Mac OS X or Linux (note that they differ from each other even!). Robert___ 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: extattr_set_*() return type
On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote: On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote: Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes written, shouldn't their return value be 'ssize_t' instead of 'int'? It looks like the system calls themselves already do the right thing in setting td_retval[] (they assign a ssize_t to it and td_retval[0] can hold a ssize_t on all of our current platforms). It would seem that the only change would be to the header and probably syscalls.master. I guess this would require a symver bump to fix though. An extended attribute larger than 2GB is a programming abuse, though. Technically int may not be 32 bits but it is on all supported platforms now. Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by some. :) The type should match the documented behavior. On OS X the set operation doesn't return a size but instead returns a simple success/failure (0 or -1) for which an int is appropriate. However, the FreeBSD API documents that it operates like write and consumes the buffer. Note that the size of the buffer passed to the 'set' and 'get' operations is a size_t, not an int, and the 'get' operations already return a ssize_t, not an int. Note that read(2)/write(2) do return int. I still have WIP patch to fix this, but after some conversations with Bruce I am not sure it is worth finishing. pgpGVG18c7Kk7.pgp Description: PGP signature
Re: r228700 can't dhclient em0
On Wed, Dec 21, 2011 at 04:55:40PM +0400, Gleb Smirnoff wrote: Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B While this is the documented path, it's not actually been required B except in edge cases for ages (the last I can remember is a.out-elf). B It's been long enough that I don't think we can really make people do B it except for a short period of time in HEAD. I believe it's B unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. I hope, this change would satisfy you, and you won't say that We almost certainly need to back r228571 out. Thank you! I spoke too strongly there. I was worried that we would end up in an untenable situation, but you appear to have resolved it. The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions dhclient, I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 So, if we are claiming for an undocumented but important feature that new kernel being capable to configure network with world from a previous major release, then I should merge r228463 right now to stable/9, and not merge r228313. If I don't merge r228463 before 9.0-RELEASE is out, then in 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with world from 9.0-RELEASE. Thus, should I now either bribe re@ to push r228463 prior to release, either back out the bugfix: r228463. You and bz have convinced me that for the configuration tools tools this change breaks, that it should be OK to have only supported 9.x releases (or possibly even only the last 9.x release) be able to upgrade without extra effort. I took too strong a position to start out. Also, backing out r228463 would require backing out a larger work: r228455. Hey, this policy greatly discourages hacking on bugs and new features... :( I hope we're approaching a more acceptable position... I don't want to discourage fixing bugs or adding features and more than having to deal with users inevitably does. -- Brooks pgpNKlBWWf6s2.pgp Description: PGP signature
Re: a few usb issues related to edge cases
On Wednesday 21 December 2011 12:29:49 Andriy Gapon wrote: on 20/12/2011 14:25 Andriy Gapon said the following: I just wanted to draw your attention to the fact that obtaining any locks in the kdb context (or USB polling code in general, even) is not a good idea. Chances of getting into trouble on those locks are probably quite moderate or even low, but they do exist. I am not sure if you are getting any bug reports about such troubles :-) Regular users probably do not use kdb too often and a panic for them is just a crash, so they likely do not expect anything usable/debuggable after that :-) Looking some more at the code I just got myself confused as to how the dumping to a umass device could work when the scheduler is stopped. It seems that the umass_command_start - usbd_transfer_start - usbd_callback_ss_done_defer functions would always put a transfer request onto a queue and try to wake up a thread to process that queue and the request. But that's obviously not going to work when the other thread is not going to be run. Have I missed a code path that leads directly to the controller in this context? Thank you for your help. Hi, Those threads should be polled when calling usbd_transfer_poll(). I.E. the wakeup should be stubbed in the !scheduler_running case. --HPS ___ 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: extattr_set_*() return type
On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote: On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote: On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote: Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes written, shouldn't their return value be 'ssize_t' instead of 'int'? It looks like the system calls themselves already do the right thing in setting td_retval[] (they assign a ssize_t to it and td_retval[0] can hold a ssize_t on all of our current platforms). It would seem that the only change would be to the header and probably syscalls.master. I guess this would require a symver bump to fix though. An extended attribute larger than 2GB is a programming abuse, though. Technically int may not be 32 bits but it is on all supported platforms now. Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by some. :) The type should match the documented behavior. On OS X the set operation doesn't return a size but instead returns a simple success/failure (0 or -1) for which an int is appropriate. However, the FreeBSD API documents that it operates like write and consumes the buffer. Note that the size of the buffer passed to the 'set' and 'get' operations is a size_t, not an int, and the 'get' operations already return a ssize_t, not an int. Note that read(2)/write(2) do return int. I still have WIP patch to fix this, but after some conversations with Bruce I am not sure it is worth finishing. The manpages and /usr/include/unistd.h claim they return ssize_t. Is this related to the changes to make uio_resid a size_t (I thought that went into the tree)? If the problem is that the values read/write return may fall into the range of only an int even on 64-bit platforms, that is different from the return type which is part of the ABI. -- John Baldwin ___ 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: extattr_set_*() return type
On Wednesday, December 21, 2011 11:02:24 am Robert N. M. Watson wrote: On 21 Dec 2011, at 15:31, John Baldwin wrote: On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote: Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes written, shouldn't their return value be 'ssize_t' instead of 'int'? It looks like the system calls themselves already do the right thing in setting td_retval[] (they assign a ssize_t to it and td_retval[0] can hold a ssize_t on all of our current platforms). It would seem that the only change would be to the header and probably syscalls.master. I guess this would require a symver bump to fix though. An extended attribute larger than 2GB is a programming abuse, though. Technically int may not be 32 bits but it is on all supported platforms now. Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse by some. :) The type should match the documented behavior. On OS X the set operation doesn't return a size but instead returns a simple success/failure (0 or -1) for which an int is appropriate. However, the FreeBSD API documents that it operates like write and consumes the buffer. Note that the size of the buffer passed to the 'set' and 'get' operations is a size_t, not an int, and the 'get' operations already return a ssize_t, not an int. Using an int was probably a bug. If we can switch to a ssize_t without undue disruption, it seems worthwhile to do so. There was never EA API standardisation, and it might be worth pondering whether to pick up additional API variants matching Mac OS X or Linux (note that they differ from each other even!). I think the system call already returns a ssize_t, so the only real change would be to change the header and bump the symver in userland leaving the old versions as still returning an int. I'm not even sure if that is strictly necessary or if we could get away with just changing the header and be done with it. -- John Baldwin ___ 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: a few usb issues related to edge cases
on 21/12/2011 18:38 Hans Petter Selasky said the following: On Wednesday 21 December 2011 12:29:49 Andriy Gapon wrote: on 20/12/2011 14:25 Andriy Gapon said the following: I just wanted to draw your attention to the fact that obtaining any locks in the kdb context (or USB polling code in general, even) is not a good idea. Chances of getting into trouble on those locks are probably quite moderate or even low, but they do exist. I am not sure if you are getting any bug reports about such troubles :-) Regular users probably do not use kdb too often and a panic for them is just a crash, so they likely do not expect anything usable/debuggable after that :-) Looking some more at the code I just got myself confused as to how the dumping to a umass device could work when the scheduler is stopped. It seems that the umass_command_start - usbd_transfer_start - usbd_callback_ss_done_defer functions would always put a transfer request onto a queue and try to wake up a thread to process that queue and the request. But that's obviously not going to work when the other thread is not going to be run. Have I missed a code path that leads directly to the controller in this context? Thank you for your help. Hi, Those threads should be polled when calling usbd_transfer_poll(). I.E. the wakeup should be stubbed in the !scheduler_running case. Ah, that's what I missed! -- Andriy Gapon ___ 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, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. O. Hartmann ohart...@zedat.fu-berlin.de hat geschrieben:On 12/20/11 21:20, Igor Mozolevsky wrote: Interestingly, while people seem to be (arguably rightly) focused on criticising Phoronix's benchmarking, nobody has offered an alternative benchmark; and while (again, arguably rightly) it is important to benchmark real world performance, equally, nobody has offered any numbers in relation to, for example, HTTP or SMTP, or any other real world-application torture tests done on the aforementioned two platforms... IMO, this just goes to show that doing is hard and criticising is much easier (yes, I am aware of the irony involved in making this statement, but someone has to!) Cheers, Igor M :-) Unfortunately, M. Larabel is the only one who's performing benchmarks on FreeBSD, comparing its performance to the Linux-opponents. Adn indeed, there is a lot of criticism, but no alternative. I said unfortunately - not offensive - since Larabel and Phoronix are sadly the only ones who do actually such bechmarking. It would be much more nicer and kind to support those people. Well, in January/February we get new hardware. One box is supposed to do number crunching via 12 cores and a TESLA GPU. My colleague is developing a high parallelized peice of software for satellite data transformation. The software package is CPU bound, partially GPU, but massively memory hungry (96 to 128 GB RAM is needed). What I can offer is, since I will also work on that machine and I've free hand to administer, in the spare time of doing my PhD, installing FreeBSD 9.0/10.0 besides SuSe Linux and looking forward having one ZFS data storage drive for homes, so both systems can perform on a most recent ZFS. I'm new to Linux, not a BSD guru, nor I'm a professional programmer/developer. My skills are sufficient for the daily scientific work. So, without pressure, I'm willing to perform some HPC benchmarks under advice if the day comes and those interested in bare numbers of FreeBSD vs. Linux performance with a real-world-scientific application. I would appreciate to see some of the developers and/or FreeBSD hackers to help Phoronix setting up a proper testenvironment instead of bashing M. Larabel and his fellows. Regards, Oliver ___ 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: extattr_set_*() return type
On Wed, Dec 21, 2011 at 12:25:18PM -0500, John Baldwin wrote:
On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote:
On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote:
On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote:
On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote:
Hmm, if these functions are expected to operate like 'write(2)' and
are
supposed to return the number of bytes written, shouldn't their
return value
be 'ssize_t' instead of 'int'? It looks like the system calls
themselves
already do the right thing in setting td_retval[] (they assign a
ssize_t to it
and td_retval[0] can hold a ssize_t on all of our current platforms).
It
would seem that the only change would be to the header and probably
syscalls.master. I guess this would require a symver bump to fix
though.
An extended attribute larger than 2GB is a programming abuse, though.
Technically int may not be 32 bits but it is on all supported
platforms now.
Today it is an abuse. In the 90's a 64-bit off_t was considered an abuse
by
some. :)
The type should match the documented behavior. On OS X the set operation
doesn't return a size but instead returns a simple success/failure (0 or
-1)
for which an int is appropriate. However, the FreeBSD API documents that
it
operates like write and consumes the buffer. Note that the size of the
buffer passed to the 'set' and 'get' operations is a size_t, not an int,
and
the 'get' operations already return a ssize_t, not an int.
Note that read(2)/write(2) do return int. I still have WIP patch to fix
this, but after some conversations with Bruce I am not sure it is worth
finishing.
The manpages and /usr/include/unistd.h claim they return ssize_t. Is this
related to the changes to make uio_resid a size_t (I thought that went into
the tree)? If the problem is that the values read/write return may fall into
the range of only an int even on 64-bit platforms, that is different from the
return type which is part of the ABI.
Yes, it is related. The type change for uio was done in advance.
Take a look at the first statement of sys_read() and sys_write():
if (uap-nbyte INT_MAX)
return (EINVAL);
and at the copyinio(), which is used by scatter/gather versions of i/o
syscalls to copy in uiovec:
if (iov-iov_len INT_MAX - uio-uio_resid) {
free(uio, M_IOV);
return (EINVAL);
pgp0QFlBvfWRz.pgp
Description: PGP signature
Re: r228700 can't dhclient em0
On 12/21/2011 4:55 AM, Gleb Smirnoff wrote: Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B While this is the documented path, it's not actually been required B except in edge cases for ages (the last I can remember is a.out-elf). B It's been long enough that I don't think we can really make people do B it except for a short period of time in HEAD. I believe it's B unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. So does that mean that if I upgrade to the latest HEAD from a system built before the ifconfig changes that when I reboot my network will come up? I hope, this change would satisfy you, and you won't say that We almost certainly need to back r228571 out. I think Brooks raised some really good points about backward compatibility, but it sounds to me like you've addressed them. In any case, my original concern was limited to Do we need an UPDATING entry? :) The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions dhclient, I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 Right, I saw those go by, which is why I tried not to jump too hard on ifconfig is broken since I wasn't sure which change was causing my problem. It sounds like you're saying that perhaps I still won't be able to get the network up after booting a new kernel without also installing part of the new world? Perhaps an UPDATING entry is needed after all? Hey, this policy greatly discourages hacking on bugs and new features... :( Learning how to innovate while providing backwards compatibility is a valuable skill. Think of this as an opportunity. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: extattr_set_*() return type
On Wednesday, December 21, 2011 3:28:42 pm Kostik Belousov wrote:
On Wed, Dec 21, 2011 at 12:25:18PM -0500, John Baldwin wrote:
On Wednesday, December 21, 2011 11:13:10 am Kostik Belousov wrote:
On Wed, Dec 21, 2011 at 10:31:11AM -0500, John Baldwin wrote:
On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote:
On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org
wrote:
Hmm, if these functions are expected to operate like 'write(2)' and
are
supposed to return the number of bytes written, shouldn't their
return value
be 'ssize_t' instead of 'int'? It looks like the system calls
themselves
already do the right thing in setting td_retval[] (they assign a
ssize_t to it
and td_retval[0] can hold a ssize_t on all of our current
platforms). It
would seem that the only change would be to the header and probably
syscalls.master. I guess this would require a symver bump to fix
though.
An extended attribute larger than 2GB is a programming abuse, though.
Technically int may not be 32 bits but it is on all supported
platforms now.
Today it is an abuse. In the 90's a 64-bit off_t was considered an
abuse by
some. :)
The type should match the documented behavior. On OS X the set
operation
doesn't return a size but instead returns a simple success/failure (0
or -1)
for which an int is appropriate. However, the FreeBSD API documents
that it
operates like write and consumes the buffer. Note that the size of the
buffer passed to the 'set' and 'get' operations is a size_t, not an
int, and
the 'get' operations already return a ssize_t, not an int.
Note that read(2)/write(2) do return int. I still have WIP patch to fix
this, but after some conversations with Bruce I am not sure it is worth
finishing.
The manpages and /usr/include/unistd.h claim they return ssize_t. Is this
related to the changes to make uio_resid a size_t (I thought that went into
the tree)? If the problem is that the values read/write return may fall
into
the range of only an int even on 64-bit platforms, that is different from
the
return type which is part of the ABI.
Yes, it is related. The type change for uio was done in advance.
Take a look at the first statement of sys_read() and sys_write():
if (uap-nbyte INT_MAX)
return (EINVAL);
and at the copyinio(), which is used by scatter/gather versions of i/o
syscalls to copy in uiovec:
if (iov-iov_len INT_MAX - uio-uio_resid) {
free(uio, M_IOV);
return (EINVAL);
Fair enough, but that is more of an implementation detail. The API/ABI is still
correct and uses ssize_t. :)
--
John Baldwin
___
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: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: Considering r228571: we need to specify vhid as additional address attribute in atomic manner, via one ioctl(). Address can't be first configured, and then made redundant, that would lead it to being static for a short period, sending gratutious ARP announcement, etc. An assumption that we are not allowed to change ABI for our own tools strongly discourages bringing in new features :( Consider changing to a more flexible ABI that does not need to be broken for new features. Examples are nmount(2)'s name-value pairs and GEOM's XML topology descriptions. This is initially more work and has poorer performance, but it may well be worth it. Process information reserves space in structures for future extension; this is less flexible but performs better (which matters somewhat). Another consideration is compatibility for 32-bit applications on 64-bit kernels; a good ABI design will minimize the amount of code needed to support that. -- Jilles Tjoelker ___ 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
Alexander Leidinger schreef: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. ___ 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 Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. To compare it with Formula1 cars. If Mercedes decide to use the engine from 2 seasons back (the engine version 4.2.1) in there 2012 car, and Ferrari uses there new Engine (version 4.7). Can we not compare them anymore because of the decission from Mercedes to use the old engine? No we just say, if you want to win a race, get the Ferrari. It is the reallity, FreeBSD uses 4.2.1 as there compiler!!! If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. I my opinion, you benchmark the latest release of Linux, FreeBSD, Solaris, Windows and whatever OS you want to compare! You want to benchmark the release and not a tuned version against a standard version. And that in general are the versions most of us users will use. And what if in the future LLVM gets on par with Linux, is it stil fair to compare FreeBSD with Linux? Or do we say, well we are on par, but it is not fair, yes we used the latest releases, but you can not blame Linux because they are still using GCC. No what we will see then are haleluja blogs that FreeBSD is on par with Linux. For me peformance is not a show stopper, and for the most of us i think it is not. FreeBSD for me is a clean system that does the job perfect and has a very helpful community. regards, Johan ___ 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 Wed, Dec 21, 2011 at 1:49 PM, Johan Hendriks joh.hendr...@gmail.com wrote: Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. When benchmarking two systems, you need to make sure that everything possible is the same (constants) and that the only differences between the two systems are what you want to benchmark (variables). For example, if you want to compare the performance of GCC-compiled binaries, then you would use the same hardware host, the same OS install, the same source code, and only change the compiler versions used to compile the benchmark binaries. That way, the only variable is version of GCC, everything else is constant, and thus the benchmark is actually testing the performance of GCC. Likewise, if you want to benchmark the performance of two OSes, you need to eliminate as many variables as possible: - same hardware - running the same benchmark binaries - using the same versions of GCC - using the same filesystems - etc That gives you the starting point. Then, you modify one of the constants above, and re-run the benchmarks. Then you modify one more of the constants above, and re-run the benchmarks. Etc. Each time, you vary only 1 thing, so that you can measure the impact of that *ONE* thing. Comparing random binary compile with GCC X on FreeBSD Y on filesystem Z on hardware config A against random binary built with GCC Q on Linux R on fileystem S on hardware config B doesn't show anything. Was the performance difference due to hardware? Filesystem? OS? GCC version? Something else? You can't use a shotgun the thread a needle. :) And what if in the future LLVM gets on par with Linux, is it stil fair to compare FreeBSD with Linux? Then you add compiler suite to the list of variables, and you make it a constant in the first run, and then vary it one piece at a time in later runs, to isolate whether or not it affects performance. In order to do a proper comparison of any two things, you have to first make them as equal as possible, and then vary things one bit at a time until you are at the default configuration for each. Only then can you really, truly, empirically say why A is better/faster/more-uber than B. Unfortunately, doing it right requires a lot of time, effort, time, and more time. -- Freddie Cash fjwc...@gmail.com ___ 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
xdm/login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5 not found
OS: FreeBSD 10.0-CURRENT/amd64 r228787 Since the last update of world yesterday were I managed to compile the OS WITH_LIBCPLUSPLUS=YES in /etc/src.conf, only root is capable to login on the console. I use OpenLDAP 2.4 as the backend for usual users, having also an emergency user installed in the local /etc/passwd just in case. The problem is, I can not login via xdm or console login anymore as any usual user, even not as a user residing in the local passwd file. Trying to login as LDAP backed user, I get the error SASL/DIGEST-MD5 authentication started Login icorrect Inspecting /var/log/auth.log reveals for this incident login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5: No such file or directory Trying tologin as a local (/etc/passwd backed) user gets sometimes the same login issue, but sporadically I get a login but landing in / instead of /home/user. /home is a ZFS volume. I reinstalled pam_ldap, nss_ldap, openldap-sasl-server/client many times now since I suspected a fault in compilation (everything is compiled via CLANG), but I have no success. /usr/local/lib/pam_ldap.so.5 does not exist, it is simply pam_ldap.so. It seems, that the OS can not find the homes on the ZFS volume. Doing a su - USER works for all LDAP users but not the local users, I receive the error su: no directory. This is very strange. While su - as root does not work, login as such a failing user work, but as mentioned without home. The last thing I did on that box is: I recompiled yesterday evening world, switched the box off. When I switched the box on today, I ran into this issue. I recompile the system without flag WITH_LIBCPLUSPLUS and see what is happening. Do others also see this strange behaviour? Regards, Oliver ___ 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 21 December 2011 22:03, Freddie Cash fjwc...@gmail.com wrote: On Wed, Dec 21, 2011 at 1:49 PM, Johan Hendriks joh.hendr...@gmail.com wrote: Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. When benchmarking two systems, you need to make sure that everything possible is the same (constants) and that the only differences between the two systems are what you want to benchmark (variables). Yes and no, but to be perfectly frank, the statement, as it stands, is a bit of a nonsense. Let me illustrate in a different way. This is macro~ vs micro~comparison of systems and depends on what you are trying to get out of the benchmark. Using the same argument one can say that Ferrari F430 vs Toyota Prius is a meaningless comparison because the under-the-hood equipment is different. Now, it is absolutely correct to say that in A vs B comparisons, only one thing should be changed and the rest should remain constant. The important thing is, however, to determine the scope of your benchmark: you are not benchmarking a component of A vs a component of B, but you are benchmarking A as a whole system and B as a whole system. Thus, the thing that changes is the system itself. Going back to F430 vs Prius, you first decide what you want to benchmark (acceleration, top speed, fuel consumption, ride comfort, c) then you measure that aspect in each of the system---you are not looking at the wiring, engine, wheels, c individually but *at a whole system*. You use the same route, time of day, driver, drive pattern, weather conditions, c, the only thing that changes is the car! Similarly, FreeBSD vs Linux, you want to a) determine what metric you want to benchmark (NFS throughput, HTTP client handling, SMPT throughput, prime number computation) and b) *scientifically* measure the system against that metric... This would essentially amount to having identical set up and tests, and only changing the hard disks (one containing Linux and another one containing FreeBSD). I don't see why this is such a difficult concept to grasp. Cheers, -- Igor M. :-) ___ 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 Wed, Dec 21, 2011 at 10:49 PM, Johan Hendriks joh.hendr...@gmail.com wrote: Alexander Leidinger schreef: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. (...) It does, though? It's in ports. The system compiler is for the system, but if you're compiling ports or standalone software you certainly can - and sometimes must - use something else. The point of that section seems to be if you're compiling userland software to compare, at least compile it with the same compiler, unless that's what you want to benchmark. Sensible enough. As for what the kernel is compiled with, I doubt that will have the same kind of effect as what the user software is compiled with. The kernel is compiled with very conservative settings anyway, and I don't think it really does much of the kind of heavy computation that benefits the most from better compilers. The most interesting part is probably the effect on the userland libraries. Has anyone done any tests on how much of an effect on user software performance it has if you change the compiler for the libraries in the base system? (I would guess not massive, but this is one of those things where some numbers wouldn't hurt). Oh, and remember that clang also works as a system compiler, and we're definitely not stuck on an old version of that. It produces code with performance comparable to gcc today, and I doubt it'll fall horribly behind in the foreseeable future. -- Daniel Nebdal ___ 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 21.12.11 23:49, Johan Hendriks wrote: I my opinion, you benchmark the latest release of Linux, FreeBSD, Solaris, Windows and whatever OS you want to compare! There is no 'general benchmark' as there is not one single tasks that all computers are used for. If you want to benchmark something, then you define that something, tune all test subjects appropriately for that one thing and run the same test load. You then go on and claim 'for task X, the OS Y was best, followed by ...'. This is what people have done for PostgreSQL for example. You may try to see how, with that same settings different OS will perform with varying conditions, like what the PostgreSQL test did -- performance over the network and performance to localhost. Testing a system, tuned for a file server as X workstations will not tell you much about the abilities of the different operating systems to run a web server, or either file server or X workstation. By the way, the gcc in 8-stable is gcc version 4.2.2 20070831 prerelease [FreeBSD] Daniel ___ 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 22.12.11 00:33, Igor Mozolevsky wrote: Using the same argument one can say that Ferrari F430 vs Toyota Prius is a meaningless comparison because the under-the-hood equipment is different. Of course, it is meaningless, the Ferrari will lose big time in the fuel consumption comparison! I believe it will also lose the price comparison as well. Not to speak the availability comparison. You say that comparison is meaningless, yet you intend to compare those two cars? Any 'benchmark' has a goal. You first define the goal and then measure how different contenders achieve it. Reaching the goal may have several measurable metrics, that you will use to later declare the winner in each. Besides, you need to define a baseline and be aware of what theoretical max/min values are possible. Daniel ___ 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 21.12.2011 22:49, schrieb Johan Hendriks: Nice page, but one thing i do not get is the following. [quote] If you compare FreeBSD / GCC 4.2.1 against, for example, Ubuntu / GCC 4.7 then the results are unlikely to tell you anything meaningful about FreeBSD vs Ubuntu. [/quote] That is a little strange in my opinion. It tells me that FreeBSD falls more and more behind on Linux. The reason is or could be that FreeBSD cannot or will not include GCC 4.7 and that FreeBSD will not be on par with Linux anymore. To compare it with Formula1 cars. If Mercedes decide to use the engine from 2 seasons back (the engine version 4.2.1) in there 2012 car, and Ferrari uses there new Engine (version 4.7). Can we not compare them anymore because of the decission from Mercedes to use the old engine? No we just say, if you want to win a race, get the Ferrari. It is the reallity, FreeBSD uses 4.2.1 as there compiler!!! As has been pointed out by others, FreeBSD ships with gcc-4.2.1 (with some local modifications and fixes) as the system compiler. If you tune up FreeBSD to use the GCC 4.7 compiler, or downgrade linux to 4.2.1, then that will tell me nothing about FreeBSD vs Linux. The gcc version distributed with FreeBSD was chosen for license reasons, not for technical reasons. If you are OK with installing a GPLv3 licensed compiler on your systems, then just do it and take advantage of the improved code generated by it. I my opinion, you benchmark the latest release of Linux, FreeBSD, Solaris, Windows and whatever OS you want to compare! As you probably know, Linux is just the kernel and the distributions add user space programs, including a compiler. You can easily create a FreeBSD distribution with more advanced compiler and use or even sell it. But the FreeBSD project was cautious to not heavily depend on a GPLv3 compiler (for reasons openly discussed at the time this decision was made). You want to benchmark the release and not a tuned version against a standard version. And that in general are the versions most of us users will use. If you compare operating systems from a technical point of view, then you'll be interested in relative performance of algorithms and methods chosen. This is best achieved by using the same compiler for each of the candidates. If you compare performance from a user point of view, you are correct that performance delivered out of the box (without complicated tuning) may be, what counts for most users. But those users that depend on best performance e.g. for a FreeBSD based embedded product or a data center, may tune the system, including compilation with a newer compiler than the system default. And what if in the future LLVM gets on par with Linux, is it stil fair to compare FreeBSD with Linux? You can always compare anything with whatever you like (even apples with oranges), but you need to be aware of what you compare and what your goals are, to be able to draw reasonable conclusions. If you want to test out of the box performance, then test with system compilers (or just those binaries delivered with the system). If you want to test for code efficiency or scalability, then use the same compilers for each system under test to remove differences introduced by the compilers (which are an external component not developed by the FreeBSD people). Or do we say, well we are on par, but it is not fair, yes we used the latest releases, but you can not blame Linux because they are still using GCC. Depends on what you want or need to measure ... No what we will see then are haleluja blogs that FreeBSD is on par with Linux. Such blog messages are not common in the FreeBSD community. FreeBSD used to have big technical and performance advantages when Linux was young, but even then, there was technical discussion between camps (and many concepts were implemented in Linux based on BSD examples; I have taken part in such discussions myself, some 15 to 20 years back). For me peformance is not a show stopper, and for the most of us i think it is not. FreeBSD for me is a clean system that does the job perfect and has a very helpful community. Well, this are valid aspects, too, and very hard to with benchmarks ;-) 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: r228700 can't dhclient em0
On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: D B While this is the documented path, it's not actually been required D B except in edge cases for ages (the last I can remember is a.out-elf). D B It's been long enough that I don't think we can really make people do D B it except for a short period of time in HEAD. I believe it's D B unacceptable for a release to release upgrade. D D I have provided API compatibility in r228768. I have tested it with an D ifconfig binary taken from 9.0 installation. D D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. D I think Brooks raised some really good points about backward D compatibility, but it sounds to me like you've addressed them. In any D case, my original concern was limited to Do we need an UPDATING entry? :) r228571 put an updating entry. D Since subject mentions dhclient, I must notice that the dhclient-script D always relied on a bug in in_control(). The bug was fixed here: D D http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 D D Later the dhclient-script was fixed: D D http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 D D Right, I saw those go by, which is why I tried not to jump too hard on D ifconfig is broken since I wasn't sure which change was causing my D problem. It sounds like you're saying that perhaps I still won't be able D to get the network up after booting a new kernel without also installing D part of the new world? Perhaps an UPDATING entry is needed after all? On the second thought, I understand that r228313 breaks the dhclient-script only for people running two DHCP interfaces. If one obtains default route, then second can't run dhclient. I'm afraid, if we would try to document every kernel-userland API/ABI change in head/ in the UPDATING, then the file will grow extremely quickly, and still many issues will be forgotten to be added there. -- 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
