Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hi, I extended the gcc part a little bit to make it a little bit more clear when it matters. Bye, Alexander. -- Send via an Android device, please forgive brevity and typographic and spelling errors. Stefan Esser hat geschrieben: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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Stefan Esser schreef: 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. It does not matter what the decission is to use the old compiler, it is a fact that the base comes with 4.2.x Does that mean we can not compare/benchmark against other distributions because they use GPLv3 stuff. No, i want to know where standard released FreeBSD stands against standard released Linux distributions. If you compare benchmark userland applictions, then it is fair to use the latest compiler for the userland software also on FreeBSD. But what if the ports tree defaults to LLVM, then again we want to know what FreeBSD does against a Linux distribution. Why because that is what most of us will be using...!! If we start to compile all the ports with gcc 4.7 to be on par in comparising and benchmarking, why spend all the time getting LLVM as the default compiler for ports also? Why not take that effort into making the WHOLE ports tree to compile with GCC4.7? Reason, because FreeBSD goes the LLVM route. That is a decission FreeBSD is making! And that choise will be the FreeBSD that is used in comparising and benchmarks on the net , not the utterly overcopiled and tuned FreeBSD against stock Ubuntu or whatever Linux distribution. If it is a good or bad choice! That we will see in the comparising/benchmarks we will be seeing when that time comes. Same goes for the scheduler! and all the other subsystems FreeBSD has choosen, that makes FreeBSD. 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). I know Linux is a kernel, re read Linux as Linux Distribution! Yes you can use a more advanced compiler on FreeBSD, BUT you can do that on Linux also ,so where do you stop? Are you going to spend a month to compare a fullly tuned up FreeBSD system against a Linux distribution? No because the users will not spend months tuning and recompile there servers. They use the FreeBSD version that comes with the CD! And that we want to compare/benchmark against a Linux distribution. 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
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
My thoughts about benchmarking - don't forget, it's the way to get at least estimate on how your system will behave in given circumstances. When testers measured new videocard, they tested few factors, like FPS in modern games, pixel/texture fillrate, and whatever they do there else. That's because videocard have few simple and plain applications. And different vendor/generation cards are compared without problems. Different version of compiler, OS, etc - is very irrelevant. It's like say we can't compare these shovels, because they made from different sort of wood. OS is created to serve (produce some useful actions), and not to be measured and turned off forever:) So, in ideal world, there will be benchmarks on some real-world situations (like FPS for videocards, there got to be something also if not common, but at least wide-spread amongst users). Like - benchmarking fully tuned FreeBSD vs fully tuned Linux in high net-load (for example http + php + mysql). It's hard to disagree that this is very common spread use case for server OS. Also good tests would be productivity of FTP/File/Samba/Nfs/rsync servers. For desktop aspects, there's not much space for tuning (for linuxes), mostly linuxes tested out-of-box, or tuned via some gui-settings applet;, while FreeBSD-OOB needs some additional care (like get latest ports, install latest video drivers, xorg, etc., sysctl tuning probably). I'm glad there's PC-BSD, and PC-BSD can be used for desktop testing. And what to test in desktop? IMHO - WM responsiveness; - Program multi-tasking, and how productivity decreases when many background program working; (It's like, which user experience we'll get when our system is pretty heavy loaded) - Probably would be fair to compare same software in same circumstances (like same version of FF, Chromium, maybe something else). There's such extension for FF imacros - which can be used to simulate user actions, any actions in many tabs; - Overall usage experience, like measure time between program launching and window appearing (file managers, browsers, settings applet, calculator, etc.) - Sleep/Wake times with empty system(and with many programs launched ); If at all supported sleep/wake (as for me - my laptop can be slept, but deny to wake properly) - Time between you press "KDE start menu icon" and menu appeared; - Your variant?... This would be more careful benchmarking, not only number-crunching and heavy-archiving is used by all peoples. And this benchmarking can be at least be applied for users; They can imagine how it is - to have dolphin (KDE file manager) launched in 1.03 seconds, and alt-tabbing gives new window in 0.2 seconds, when video is playing. But what about time of calculating of Super-PI? Or archiving 4Gb file? It's mostly abstract measurement, and almost useless; I repeat - for average desktop users. I've at work PC-BSD installed on 24Gb SSD, with default ZFS setup slightly tuned (disabled prefetch), and I can say that system is great, and not sluggish. I sometimes happen to fill FS to 100%, then delete logs and continue working, without any signs of ZFS problems (I read somewhere that ZFS don't like to work when not much of free space available). KDE is old, but pretty fast. How can I measure this all with some few numbers :) ? My point is, that if not now, then in some near future benchmarking need to be more practical and applicable for users. Desktop measurements and server measurements. I hope Phoronix test suite will support desktop-experience benchmarking soon :) Thanks. -- Regards, Alexander Yerenkow ___ 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 11:02, Johan Hendriks wrote: Stefan Esser schreef: Am 21.12.2011 22:49, schrieb Johan Hendriks: 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. It does not matter what the decission is to use the old compiler, it is a fact that the base comes with 4.2.x Does that mean we can not compare/benchmark against other distributions because they use GPLv3 stuff. If you intend to compare operating systems 'as shipped', then forget about comparing third party programs on top of these operating systems. Compare only any software that is already available with the operating system, as shipped. There is plenty of software in the base system and this software is specifically different (say) in FreeBSD and Linux. Anyone made such comparison? No, i want to know where standard released FreeBSD stands against standard released Linux distributions. If you compare benchmark userland applictions, then it is fair to use the latest compiler for the userland software also on FreeBSD. But what if the ports tree defaults to LLVM, then again we want to know what FreeBSD does against a Linux distribution. Why because that is what most of us will be using...!! It is pretty easy to tell the ports system to use latest gcc, as described here http://www.freebsd.org/doc/en/articles/custom-gcc/article.html If we start to compile all the ports with gcc 4.7 to be on par in comparising and benchmarking, why spend all the time getting LLVM as the default compiler for ports also? Because, FreeBSD attempts to be as GPL free as possible. GPL is incompatible with many of the applications of FreeBSD. Why not take that effort into making the WHOLE ports tree to compile with GCC4.7? This has already been done. See above. Reason, because FreeBSD goes the LLVM route. That is a decission FreeBSD is making! LLVM, as well as GCC are just choices in FreeBSD. What FreeBSD is making is, to make it safe to use LLVM to compile everything on FreeBSD, including the kernel. As you may have already noticed, some ports require to be compiled with a specific version of gcc, or a very specific compiler -- there is nothing wrong with this -- this is external software after all. And that choise will be the FreeBSD that is used in comparising and benchmarks on the net , not the utterly overcopiled and tuned FreeBSD against stock Ubuntu or whatever Linux distribution. Earlier on this thread I mentioned, that FreeBSD and Linux philosophies differ. While Linux (well, some distributions, to be correct) will try to optimize certain parts of the OS/applications in order to do well in benchmarks -- FreeBSD takes a different approach. The FreeBSD (and BSD UNIX, in general) approach is "do the right thing". This may produce the results slower, but the environment is more stable in general and in the long run, the results noticeable better. This argument, by the way reminds me of the AT&T vs BSDI lawsuit, where at the time UCB was involved there was lengthly discussion (at court), about "sloppy programming, but we had to have something for the deadline" (AT&T) vs "well, we have designed the architecture we think is appropriate, there might be few unimplemented things, but we are working on it". Same goes for the scheduler! and all the other subsystems FreeBSD has choosen, that makes FreeBSD. What about the scheduler? Yes you can use a more advanced compiler on FreeBSD, BUT you can do that on Linux also ,so where do you stop? Can you compile the entire Linux system, kernel and userland and external packages with LLVM? Are you going to spend a month to compare a fullly tuned up FreeBSD system against a Linux distribution? I would do that, if: - I have a task for which I need tuned system (that is, hardware would be at limits); - The application is available on both; - There is evidence or suggestion that the application under Linux will perform much better; No because the users will not spend months tuning and recompile there servers. They use the FreeBSD version that comes with the CD! On servers? :-) And that we want to compare/benchmark against a Linux distribution. No, we don't. We run our servers, we don't want to compare/benchmark them with Linux for no reason. We want however to identify design or implementation weaknesses in FreeBSD and fix these. This rarely happens by comparing to Linux distributions. There are better things to be observed in say, Solaris. If we were selling FreeBSD, we would be interested in publishing benchmarks that demonstrate how superior to Linux it is. We would tune FreeBSD to beat Linux in most
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 22 December 2011 05:54, Daniel Kalchev wrote: > > > 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. That's an oxymoron, right? The comparison cannot be meaningless---the reality is F430 will indeed use up more fuel than Prius. If a benchmark demonstrates a true reality, how can that benchmark be possibly meaningless??? Same benchmark might be irrelevant to someone who wants to know how fast they can get from A to B, but irrelevant is not a synonym for meaningless! > You say that comparison is meaningless, yet you intend to compare those two > cars? I didn't say that at all, I was demonstrating fallacy of the argument that the comparisons were meaningless. > 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. Treating a benchmark as a binary win/lose is rather naive, it's not a competition, and (I hope) no serious person ever does that. A proper benchmark shows true strength and weaknesses so than a well-informed intelligent decision can be taken by an individual according to that individual's needs. The caveat, of course, is making your methodology clear and methods repeatable! 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 22.12.11 11:56, Igor Mozolevsky wrote: On 22 December 2011 05:54, Daniel Kalchev wrote: 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. That's an oxymoron, right? The comparison cannot be meaningless---the reality is F430 will indeed use up more fuel than Prius. If a benchmark demonstrates a true reality, how can that benchmark be possibly meaningless??? Same benchmark might be irrelevant to someone who wants to know how fast they can get from A to B, but irrelevant is not a synonym for meaningless! That benchmark is especially meaningless and a waste of time, because by design the Prius is constructed to consume 'less' fuel at the cost of lower engine power and the Ferrari is designed to waste fuel for the sake of high engine power. Of course, you can compare them, but this is not exactly benchmark. As for how fast to get from point A to point B. If you observe speed limits, that will depend only on the pilot, no? :) Both cars are sufficiently faster than the imposed speed limits. The same can be said for the FreeBSD and the Linux platforms. Today. Years ago, Linux was much worse, but they.. hm.. learned. :) On commodity hardware, you can expect about the same results from both OS. There will be differences due to drivers, different optimizations etc. On very specific hardware, such as systems with many CPUs and lots of memory, you may see one better than the other -- this in most cases will be relevant to tuning, but also to overall system architecture. 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. Treating a benchmark as a binary win/lose is rather naive, it's not a competition, and (I hope) no serious person ever does that. A proper benchmark shows true strength and weaknesses so than a well-informed intelligent decision can be taken by an individual according to that individual's needs. The caveat, of course, is making your methodology clear and methods repeatable! Err... a benchmark produces metrics. It does not produce conclusions. Or at least, should not :) It takes context and understanding of both the subject and methodology used to draw any conclusion out of particular benchmark. No benchmark shows strengths and weaknesses -- these are subject of interpretation and any 'score' you have in a benchmark might be the result of poor benchmark design and/or implementation. You may make an very "scientific", well documented and repeatable benchmark, such as this one: time dd if=/dev/zero of=/dev/null .. then optimize your particular OS to run it at the highest possible rate... and so what? Do you know what this benchmark measures? :) 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 December 2011 10:12, Daniel Kalchev wrote: > As for how fast to get from point A to point B. If you observe speed limits, > that will depend only on the pilot, no? :) > Both cars are sufficiently faster than the imposed speed limits. You are ignoring acceleration, handling, and other factors... Besides, you're missing the point: *given same conditions* a benchmark allows one to show how A performs compared to B, which is why I said it is important to keep everything else constant! At the end of the day, what users, sysadmins, &c want to know is given hardware configuration H and requirement R will software X outperform software Y or Z. The components and the bells and whistles of X, Y or Z are, quite often, irrelevant (unless one has some silly idealogical reason, for example). > On very specific hardware, such as systems with many CPUs and lots of > memory, you may see one better than the other -- this in most cases will be > relevant to tuning, but also to overall system architecture. Are you saying that careful tuning will give you _orders of magnitude_ performance increase? Got numbers to back that up? ;-) > You may make an very "scientific", well documented and repeatable benchmark, > such as this one: > > time dd if=/dev/zero of=/dev/null > > .. then optimize your particular OS to run it at the highest possible > rate... and so what? Do you know what this benchmark measures? :) Yes, do you? I hope you are not being deliberately obtuse here... Besides, I would criticise your test in this example: have you tried running that with, say, bs=1g count=1000? Is there a difference how fast FreeBSD completes that vs how fast a Linux box does the same? The point of documenting a repeatable benchmark is to enable the person interpreting the results to see what was done (and verify) to achieve the result and treat that result accordingly. Cheers, -- Igor ___ 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 12:50, Igor Mozolevsky wrote: On 22 December 2011 10:12, Daniel Kalchev wrote: As for how fast to get from point A to point B. If you observe speed limits, that will depend only on the pilot, no? :) Both cars are sufficiently faster than the imposed speed limits. You are ignoring acceleration, handling, and other factors... Besides, you're missing the point: *given same conditions* a benchmark allows one to show how A performs compared to B, which is why I said it is important to keep everything else constant! At the end of the day, what users, sysadmins,&c want to know is given hardware configuration H and requirement R will software X outperform software Y or Z. The components and the bells and whistles of X, Y or Z are, quite often, irrelevant (unless one has some silly idealogical reason, for example). None of the benchmarks measure 'comfort'. None of the benchmarks measure how the system 'feels' while performing an numerical computation. The benchmarks measure how soon the computations are finished. You typically achieve that by tuning the OS to say, ignore any interactivity at the cost of focusing all resources to compute-intensive tasks. If you use the same hardware, the CPU can do only so much and if there are any differences, that will be in how the OS asks the CPU to do other things, besides the task you benchmark. You need to define your criteria. Otherwise the benchmark cannot be used to make comparisons. On very specific hardware, such as systems with many CPUs and lots of memory, you may see one better than the other -- this in most cases will be relevant to tuning, but also to overall system architecture. Are you saying that careful tuning will give you _orders of magnitude_ performance increase? Got numbers to back that up? ;-) Ah.. now we are talking :) Two things: Someone once said, that you may have an very fast computation if only you need not make sure the results are correct. So yes, you can! :) It is all too easy to make things worse, from the theoretical baseline. So often we measure not how 'good' an OS is, but how 'bad' it actually manages the hardware. Well.. there is also some hardware that has limitations and you need to define the benchmark in a specific way to not touch them. Or you may have specific OS trying to avoid touching them -- and thus providing you with 'performance'. You may make an very "scientific", well documented and repeatable benchmark, such as this one: time dd if=/dev/zero of=/dev/null .. then optimize your particular OS to run it at the highest possible rate... and so what? Do you know what this benchmark measures? :) Yes, do you? I hope you are not being deliberately obtuse here... I know, that different people will see different things being measured here. Let's see if someone else will jump in. (which is the purpose of this example) Besides, I would criticise your test in this example: have you tried running that with, say, bs=1g count=1000? That would measure different things. :) Is there a difference how fast FreeBSD completes that vs how fast a Linux box does the same? Why not? I would expect there will be difference in how fast different versions of FreeBSD complete it as well. It could be also interesting to measure (although it's somewhat subjective) how interactive both systems stay during this task. 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"
GCC debug flags cleanup
Hi, I've created a patch that cleans up FreeBSD Makefiles that unconditionally set the -g flag for GCC. The motivation for this is that it should be possible to add or remove this flag globally via e.g. CFLAGS (it's part of my quest to produce deterministic builds). I'm not very familiar with GCC or the build infrastructure, so I'd be grateful if someone would review it and possibly commit. http://dev.affect-it.dk/gcc_debug_flags.diff Thanks, Erik___ 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: WITHOUT_PROFILE=yes by default
On Mon, 2011-12-19 at 12:50:42 -0700, Warner Losh wrote: > > On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote: > > >> Using profiled libs and gprof to profile your code has been obsolete > >> in FreeBSD on i386 and amd64 for over six years now. > > > > Funny, it still seems to work on my systems. > > Worked for me last time I tried as well. Was able to find the problems w/o a > hassle. turning them off is plain wrong. > > Can we at least ship profiled libraries for the release? I didn't want to get in on the discussion, but for me every time you need to recompile software to get to feature A, I consider it a bug. Rebooting to enable a feature? Sure. Recompiling software to enable a feature? What? Is this the middle ages? What happened to shipping software/binaries that can work for everybody? The way I see it, profiling currently works for *both*, users that need the libs and users that don't need the libs. Reducing compile times is not a worthy goal, IMHO, as no user should ever have need to re-compile FreeBSD. Neither to tune something in GENERIC nor to rebuild world. Just my 2 cents, Uli ___ 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"
jexec -h hostname option
http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND jexec(8) now supports -h hostname option to specify the jail where the command will be executed. When was this added? I don't see it functioning: sunsaturn:~# jexec -h jexec: illegal option -- h usage: jexec [-u username | -U username] jail command ... sunsaturn:~# uname -a FreeBSD sunsaturn.com 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec 11 19:20:46 CST 2011 dr...@sunsaturn.com:/usr/obj/usr/src/sys/MYKERNEL amd64 sunsaturn:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.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: jexec -h hostname option
On 22. Dec 2011, at 14:03 , Dan The Man wrote: > > > http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND > jexec(8) now supports -h hostname option to specify the jail where the > command will be executed. > Oh wow. That's all but current. > > When was this added? I don't see it functioning: 3 years 6 months ago and it was shortly afterwards removed again as neither a) the hostname not b) the ip addresses needed to be unique anymore with multi-IP jails (a) not even before that). The suggested replacement was -n to name the jails yourself. I think the uniqueness limit has since been removed on that as well but the option has stayed and by default is the jail ID these days and it's name=<..> in the modern syntax. /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"
[patch] Cleaning up amd64 kernel optimization options
Hi,
I would like to ask some feedback on the attached patch, which cleans up
the kernel optimization options for amd64. This was touched upon
earlier by Alexander Best in freebsd-toolchain, here:
http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-October/000270.html
What this patch attempts to fix is the following:
- When you compile amd64 kernels for debug, they still get optimized
with "-O2 -frename-registers", which is almost certain to make
debugging miserable. Optimizing at higher levels makes variables and
code move around, or disappear altogether. About -frename-registers
the gcc documentation even says: "Depending on the debug information
format adopted by the target, however, it can make debugging
impossible, since variables will no longer stay in a “home register”."
- Clang doesn't support the -frename-registers option, so you get
harmless but annoying "warning: argument unused during compilation:
'-frename-registers'" messages during buildkernel.
The patch makes it so that:
- For normal amd64 kernel builds, it uses "-O2 -frename-registers",
unless Clang is used, then it uses plain "-O2".
- For debug amd64 kernel builds, it uses "-O", just like all the other
arches.
Index: sys/conf/kern.pre.mk
===
--- sys/conf/kern.pre.mk (revision 228799)
+++ sys/conf/kern.pre.mk (working copy)
@@ -29,15 +29,13 @@
.else
.if ${MACHINE_CPUARCH} == "powerpc"
_MINUS_O= -O # gcc miscompiles some code at -O2
+.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang"
+_MINUS_O= -O2 -frename-registers
.else
_MINUS_O= -O2
.endif
.endif
-.if ${MACHINE_CPUARCH} == "amd64"
-COPTFLAGS?=-O2 -frename-registers -pipe
-.else
COPTFLAGS?=${_MINUS_O} -pipe
-.endif
.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing)
COPTFLAGS+= -fno-strict-aliasing
.endif
___
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: xdm/login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5 not found
On Wed, Dec 21, 2011 at 11:09:23PM +0100, Hartmann, O. wrote: H> OS: FreeBSD 10.0-CURRENT/amd64 r228787 H> H> Since the last update of world yesterday were I managed to compile the H> OS WITH_LIBCPLUSPLUS=YES in /etc/src.conf, H> only root is capable to login on the console. H> H> I use OpenLDAP 2.4 as the backend for usual users, having also an H> "emergency" user installed in the local /etc/passwd just in case. H> H> The problem is, I can not login via xdm or console login anymore as any H> usual user, even not as a user residing in the local passwd file. H> H> Trying to login as LDAP backed user, I get the error H> SASL/DIGEST-MD5 authentication started H> Login icorrect H> H> Inspecting /var/log/auth.log reveals for this incident H> H> login: in openpam_check_path_owner_perms(): H> /usr/local/lib/pam_ldap.so.5: No such file or directory H> H> Trying tologin as a local (/etc/passwd backed) user gets H> sometimes the same login issue, but sporadically I get a login but H> landing in / instead of /home/user. /home is a ZFS volume. H> H> I reinstalled pam_ldap, nss_ldap, openldap-sasl-server/client many times H> now since I suspected a fault in compilation (everything is compiled via H> CLANG), but I have no success. H> H> /usr/local/lib/pam_ldap.so.5 does not exist, it is simply pam_ldap.so. H> H> It seems, that the OS can not find the homes on the ZFS volume. Doing a H> su - USER works for all LDAP users but not the local users, I receive H> the error su: no directory. This is very strange. While su - as root H> does not work, login as such a failing user work, but as mentioned H> without home. H> H> The last thing I did on that box is: I recompiled yesterday evening H> world, switched the box off. When I switched the box on today, I ran H> into this issue. H> H> I recompile the system without flag WITH_LIBCPLUSPLUS and see what is H> happening. Do others also see this strange behaviour? This is definitely due to libpam update. In my case, I also got messages: openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5: No such file or directory But this doesn't prevent me from logging in. The new PAM code first tries to dlopen() a library configured in /etc/pam.d with ".5" appended to it, this is hardcoded. If failed, it dlopens the exact name from configuration. So, the message is harmless itself - the pam_ldap.so is opened successfully. I suppose failure to login that you experience is related to another fallout from the new PAM import. -- 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: jexec -h hostname option
On Thu, 22 Dec 2011, Bjoern A. Zeeb wrote: On 22. Dec 2011, at 14:03 , Dan The Man wrote: http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND jexec(8) now supports -h hostname option to specify the jail where the command will be executed. Oh wow. That's all but current. When was this added? I don't see it functioning: 3 years 6 months ago and it was shortly afterwards removed again as neither a) the hostname not b) the ip addresses needed to be unique anymore with multi-IP jails (a) not even before that). The suggested replacement was -n to name the jails yourself. I think the uniqueness limit has since been removed on that as well but the option has stayed and by default is the jail ID these days and it's name=<..> in the modern syntax. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. Yeah, seems problematic, from what I have seen so far everytime you stop and restart the jail it gets a different jail ID, which would make it difficult to cron anything to execute in the jail. I can't seem to get jexec to take anything but jail id. Came up with a temporary type solution assuming you have only 1 jail: JAILID=`/usr/sbin/jls -n name|cut -d '=' -f 2`; /usr/sbin/jexec $JAILID command I can see this being problematic for a long term/portable solution. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.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: GCC debug flags cleanup
Hi, On 22 Dec 2011, at 11:52, Erik Cederstrand wrote: > I've created a patch that cleans up FreeBSD Makefiles that unconditionally > set the -g flag for GCC. [etc] Just a note of caution that I have had cases in the past where I suspected that GCC was generating broken code without -g and good code with. Makes debugging interesting :-) -- Bob Bishop r...@gid.co.uk ___ 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: GCC debug flags cleanup
On Thu, 22 Dec 2011, Bob Bishop wrote: Hi, On 22 Dec 2011, at 11:52, Erik Cederstrand wrote: I've created a patch that cleans up FreeBSD Makefiles that unconditionally set the -g flag for GCC. [etc] Just a note of caution that I have had cases in the past where I suspected that GCC was generating broken code without -g and good code with. Makes debugging interesting :-) /me waits for PCC to be useful for compiling the whole system. :) - Mark ___ 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: [patch] Cleaning up amd64 kernel optimization options
On Thu Dec 22 11, Dimitry Andric wrote: > Hi, > > I would like to ask some feedback on the attached patch, which cleans up > the kernel optimization options for amd64. This was touched upon > earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: " I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. " however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. cheers. alex > > http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-October/000270.html > > What this patch attempts to fix is the following: > - When you compile amd64 kernels for debug, they still get optimized > with "-O2 -frename-registers", which is almost certain to make > debugging miserable. Optimizing at higher levels makes variables and > code move around, or disappear altogether. About -frename-registers > the gcc documentation even says: "Depending on the debug information > format adopted by the target, however, it can make debugging > impossible, since variables will no longer stay in a ?home register?." > - Clang doesn't support the -frename-registers option, so you get > harmless but annoying "warning: argument unused during compilation: > '-frename-registers'" messages during buildkernel. > > The patch makes it so that: > - For normal amd64 kernel builds, it uses "-O2 -frename-registers", > unless Clang is used, then it uses plain "-O2". > - For debug amd64 kernel builds, it uses "-O", just like all the other > arches. ___ 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: jexec -h hostname option
On 22. Dec 2011, at 16:03 , Dan The Man wrote: > > > On Thu, 22 Dec 2011, Bjoern A. Zeeb wrote: > >> >> On 22. Dec 2011, at 14:03 , Dan The Man wrote: >> >>> >>> >>> http://www.freebsd.org/relnotes/CURRENT/relnotes/new.html#USERLAND >>> jexec(8) now supports -h hostname option to specify the jail where the >>> command will be executed. >>> >> >> Oh wow. That's all but current. >> >> >>> >>> When was this added? I don't see it functioning: >> >> 3 years 6 months ago and it was shortly afterwards removed again as neither >> a) the hostname not b) the ip addresses needed to be unique anymore with >> multi-IP jails (a) not even before that). The suggested replacement was >> -n to name the jails yourself. I think the uniqueness limit has since been >> removed on that as well but the option has stayed and by default is the >> jail ID these days and it's name=<..> in the modern syntax. >> >> /bz >> >> -- >> Bjoern A. Zeeb You have to have visions! >>Stop bit received. Insert coin for new address family. >> >> > > Yeah, seems problematic, from what I have seen so far everytime you stop and > restart the jail it gets a different jail ID, which would make it difficult > to cron anything to execute in the jail. I can't seem to get jexec to take > anything but jail id. > > Came up with a temporary type solution assuming you have only 1 jail: > JAILID=`/usr/sbin/jls -n name|cut -d '=' -f 2`; /usr/sbin/jexec $JAILID > command > > I can see this being problematic for a long term/portable solution. jexec on a name works fine if you start the jail with a name as well. See the jail(8) man page on how to either use -n or name=. jail -n foo ... or jail name=foo ... then jexec foo ... -- 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: jexec -h hostname option
On Thu, Dec 22, 2011 at 1:31 PM, Bjoern A. Zeeb wrote: > jexec on a name works fine if you start the jail with a name as well. > See the jail(8) man page on how to either use -n or name=. > > jail -n foo ... > or > jail name=foo ... > > then jexec foo ... I've wanted to be able to do this since I read that in the jexec man page, but it doesn't seem that /etc/rc.d/jail starts jails with that option (at least in 9.0-RC3): mmullins@boron 2808 ~ % jls -n nodying enforce_statfs=2 host=new ip4=new ip6=disable jid=9 linux=new name=9 parent=0 path=/jails/shell nopersist securelevel=-1 allow.nochflags allow.nomount allow.noquotas allow.noraw_sockets allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 children.max=0 cpuset.id=2 host.domainname="" host.hostid=0 host.hostname=boron-shell.local.mmlx.us host.hostuuid=---- ip4.addr=192.168.33.40 ip4.saddrsel ip6.addr= ip6.saddrsel linux.osname=Linux linux.osrelease=2.6.16 linux.oss_version=198144 Is there a "right" way to do this? Thanks, Matt Mullins ___ 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: jexec -h hostname option
On 22. Dec 2011, at 19:39 , Matt Mullins wrote: > On Thu, Dec 22, 2011 at 1:31 PM, Bjoern A. Zeeb > wrote: >> jexec on a name works fine if you start the jail with a name as well. >> See the jail(8) man page on how to either use -n or name=. >> >> jail -n foo ... >> or >> jail name=foo ... >> >> then jexec foo ... > > I've wanted to be able to do this since I read that in the jexec man > page, but it doesn't seem that /etc/rc.d/jail starts jails with that > option (at least in 9.0-RC3): > I think -l -U root are the defaults; please double-check in /etc/defaults/rc.conf, so exntending them to: jail__flags="-l -U root -n " is easy. > mmullins@boron 2808 ~ % jls -n > nodying enforce_statfs=2 host=new ip4=new ip6=disable jid=9 linux=new > name=9 parent=0 path=/jails/shell nopersist securelevel=-1 > allow.nochflags allow.nomount allow.noquotas allow.noraw_sockets > allow.set_hostname allow.nosocket_af allow.nosysvipc children.cur=0 > children.max=0 cpuset.id=2 host.domainname="" host.hostid=0 > host.hostname=boron-shell.local.mmlx.us > host.hostuuid=---- > ip4.addr=192.168.33.40 ip4.saddrsel ip6.addr= ip6.saddrsel > linux.osname=Linux linux.osrelease=2.6.16 linux.oss_version=198144 > > Is there a "right" way to do this? > > Thanks, > Matt Mullins -- 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: r228700 can't dhclient em0
On 12/21/2011 23:20, Gleb Smirnoff wrote: > 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. That doesn't mean we shouldn't do our best to make sure that they are documented. This is particularly true regarding changes that will affect the network on reboot. In any case, thanks for the info, and for your hard work. :) 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/21/11 19:41, Alexander Leidinger wrote: > 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 to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? Oliver signature.asc Description: OpenPGP digital signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: > On 12/21/11 19:41, Alexander Leidinger wrote: > > 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 to see movement ;-) > > But there seems something unclear: > > man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in > /etc/make.conf. > The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. > > What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. -- | 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: [patch] Cleaning up amd64 kernel optimization options
On Thu, 22 Dec 2011, Alexander Best wrote: On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: i've been using such settings for a few months now and haven't noticed any problems. however bruce evans raised a good point (in a private mail). when you compile a kernel without debugging enabled, -O2 is the default. if you experience issues, and enable debugging, -O0 now becomes the default. in case the problems with the kernel were caused by the -O2 option and aren't present with the -O0 option, the newly built kernel with debugging enabled will not help you fix the problems. in that case you would need to set -O2 explicitly in CFLAGS. his exact words were: " I don't like -O2 for anything. However, if it is only a default, it is not a problem provided it can be canceled easily. And for debugging, you want the default to be the same as without debugging, so that (by default) you debug the same code that caused the problem. " however i don't think this is fixable. using -O0 for debuggable and non-debuggable kernels will cause too much of a slowdown. having -O2 as the default flag for non-debuggable kernels and -O2 -g for debuggable kernels might cause situations, where debugging isn't possible, where with -O0 -g it would have been. so i guess although bruces concerns are valid, they are impossible to solve. Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. -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: [patch] Cleaning up amd64 kernel optimization options
On Thu Dec 22 11, Benjamin Kaduk wrote: > On Thu, 22 Dec 2011, Alexander Best wrote: > > >On Thu Dec 22 11, Dimitry Andric wrote: > >>Hi, > >> > >>I would like to ask some feedback on the attached patch, which cleans up > >>the kernel optimization options for amd64. This was touched upon > >>earlier by Alexander Best in freebsd-toolchain, here: > > > >i've been using such settings for a few months now and haven't noticed any > >problems. > > > >however bruce evans raised a good point (in a private mail). when you > >compile a > >kernel without debugging enabled, -O2 is the default. if you experience > >issues, > >and enable debugging, -O0 now becomes the default. in case the problems > >with > >the kernel were caused by the -O2 option and aren't present with the -O0 > >option, the newly built kernel with debugging enabled will not help you > >fix the > >problems. in that case you would need to set -O2 explicitly in CFLAGS. his > >exact words were: > > > >" > >I don't like -O2 for anything. However, if it is only a default, it is > >not a problem provided it can be canceled easily. And for debugging, you > >want the default to be the same as without debugging, so that (by default) > >you debug the same code that caused the problem. > >" > > > >however i don't think this is fixable. using -O0 for debuggable and > >non-debuggable kernels will cause too much of a slowdown. > > > >having -O2 as the default flag for non-debuggable kernels and -O2 -g for > >debuggable kernels might cause situations, where debugging isn't possible, > >where with -O0 -g it would have been. > > > >so i guess although bruces concerns are valid, they are impossible to > >solve. > > Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. sorry. of course i meant -O: .if defined(DEBUG) _MINUS_O= -O CTFFLAGS+= -g .else [..] > > -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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/22/11 10:02, Johan Hendriks wrote: > Stefan Esser schreef: >> 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. > It does not matter what the decission is to use the old compiler, it is > a fact that the base comes with 4.2.x > Does that mean we can not compare/benchmark against other distributions > because they use GPLv3 stuff. > No, i want to know where standard released FreeBSD stands against > standard released Linux distributions. > If you compare benchmark userland applictions, then it is fair to use > the latest compiler for the userland software also on FreeBSD. > But what if the ports tree defaults to LLVM, then again we want to know > what FreeBSD does against a Linux distribution. > Why because that is what most of us will be using...!! Who ever tried to use gcc 4.6 to compile the base system knows that it is no eays task and it isn't so easy to simply change the compiler! This is also true for a lot of ports. If it is so easy to use a more modern compiler as some of the statements made here would suggest, then I would expect a dedicated chapter in the handbook! In such a case, every systems administrator trying to make a long-term decission what operating system might be the base for the future, does not need to be an enthusiastic of either BSD or Linux to understand how to tweak - fanboys, developers or enthusiasts have already choosen, apart from any rational or reason. What matters are advantages which can be approved. Downlad the DVD, install the OS, do some adjustments regarding to some pages of the manual, choose a propper set of applicable software to benchmark, compile, benchmark the system. Phoronix did so. Well, it's hard for me to find the chapter in the handbook which describes the performance tuning of SCHED_ULE and its sysctl tweaks, someone may call me stupid and point me to the page, please ... > > If we start to compile all the ports with gcc 4.7 to be on par in > comparising and benchmarking, why spend all the time getting LLVM as the > default compiler for ports also? > Why not take that effort into making the WHOLE ports tree to compile > with GCC4.7? > > Reason, because FreeBSD goes the LLVM route. That is a decission FreeBSD > is making! Yes, and it is legitime to question that and bring pro and contra for that decission. But since "FreeBSD" is obviously a small club of people sitting like a duck on eggs (and, by the way, not their own genuine invented eggs, more or less reingeneered eggs), those decissions get more obscure than they seem to be anyway. > And that choise will be the FreeBSD that is used in comparising and > benchmarks on the net , not the utterly overcopiled and tuned FreeBSD > against stock Ubuntu or whatever Linux distribution. > > If it is a good or bad choice! That we will see in the > comparising/benchmarks we will be seeing when that time comes. > > Same goes for the scheduler! and all the other subsystems FreeBSD has > choosen, that makes FreeBSD. > ... sometimes the underdog has to pick up what's left ... >> >>> 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
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/22/11 10:56, Igor Mozolevsky wrote: > On 22 December 2011 05:54, Daniel Kalchev wrote: [...] >> 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. > > Treating a benchmark as a binary win/lose is rather naive, it's not a > competition, and (I hope) no serious person ever does that. A proper > benchmark shows true strength and weaknesses so than a well-informed > intelligent decision can be taken by an individual according to that > individual's needs. The caveat, of course, is making your methodology > clear and methods repeatable! > > > Cheers, > > -- Benchmarks also could lead developers to look into more details of the weak points of their OS, if they're open for that. Therefore, benchmarks are very useful. But not if any real fault of the OS is excused by a faulty becnhmarking. I remember that the worse threaded I/O performance of FreeBSD has been long discussed as a bad benchmarks schematics. Or even look at the thread regarding to SCHED_ULE. Why has a user, experiencing really worse performance with SCHED_ULE, in a nearly scientific manner some engineer the fault? I'd expect the developer or care-taking engineer taking care in a more user friendly manner. If a benchmark reveals some severe weak points in FreeBSD and I have to read about obscure tweaks of non documented sysctl, then this OS would be a no-go if I was a manager to make decissions. And yes, i know, FreeBSD is an free and open project. But I also know that this free and open project does not rely only on "volonteers". A volunteers do not expect funding or payment. So, even freeBSD is dependend on some finacial basis and such a basis has to be taken care of. signature.asc Description: OpenPGP digital signature
Re: r228700 can't dhclient em0
On 12/21/2011 23:20, Gleb Smirnoff wrote: > On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: > > 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". I just tried with r228122 and got the same result. dhclient errors out with "can't find em0" although 'ifconfig em0' does produce results. I'm also not sure what you meant by "head > r228768" above, since we're only up to r228824 in total so far. Maybe your time machine works better than mine? :) 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: xdm/login: in openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5 not found
On 12/22/11 16:59, Gleb Smirnoff wrote: > On Wed, Dec 21, 2011 at 11:09:23PM +0100, Hartmann, O. wrote: > H> OS: FreeBSD 10.0-CURRENT/amd64 r228787 > H> > H> Since the last update of world yesterday were I managed to compile the > H> OS WITH_LIBCPLUSPLUS=YES in /etc/src.conf, > H> only root is capable to login on the console. > H> > H> I use OpenLDAP 2.4 as the backend for usual users, having also an > H> "emergency" user installed in the local /etc/passwd just in case. > H> > H> The problem is, I can not login via xdm or console login anymore as any > H> usual user, even not as a user residing in the local passwd file. > H> > H> Trying to login as LDAP backed user, I get the error > H> SASL/DIGEST-MD5 authentication started > H> Login icorrect > H> > H> Inspecting /var/log/auth.log reveals for this incident > H> > H> login: in openpam_check_path_owner_perms(): > H> /usr/local/lib/pam_ldap.so.5: No such file or directory > H> > H> Trying tologin as a local (/etc/passwd backed) user gets > H> sometimes the same login issue, but sporadically I get a login but > H> landing in / instead of /home/user. /home is a ZFS volume. > H> > H> I reinstalled pam_ldap, nss_ldap, openldap-sasl-server/client many times > H> now since I suspected a fault in compilation (everything is compiled via > H> CLANG), but I have no success. > H> > H> /usr/local/lib/pam_ldap.so.5 does not exist, it is simply pam_ldap.so. > H> > H> It seems, that the OS can not find the homes on the ZFS volume. Doing a > H> su - USER works for all LDAP users but not the local users, I receive > H> the error su: no directory. This is very strange. While su - as root > H> does not work, login as such a failing user work, but as mentioned > H> without home. > H> > H> The last thing I did on that box is: I recompiled yesterday evening > H> world, switched the box off. When I switched the box on today, I ran > H> into this issue. > H> > H> I recompile the system without flag WITH_LIBCPLUSPLUS and see what is > H> happening. Do others also see this strange behaviour? > > This is definitely due to libpam update. In my case, I also got messages: > > openpam_check_path_owner_perms(): /usr/local/lib/pam_ldap.so.5: No such file > or directory > > But this doesn't prevent me from logging in. The new PAM code first > tries to dlopen() a library configured in /etc/pam.d with ".5" appended > to it, this is hardcoded. If failed, it dlopens the exact name from > configuration. So, the message is harmless itself - the pam_ldap.so > is opened successfully. > > I suppose failure to login that you experience is related to another > fallout from the new PAM import. > With the most recent patch and make world the problem has gone! luckily ... oliver signature.asc Description: OpenPGP digital signature
Re: [patch] Cleaning up amd64 kernel optimization options
On Dec 22, 2011, at 4:59 PM, Alexander Best wrote: > On Thu Dec 22 11, Benjamin Kaduk wrote: >> On Thu, 22 Dec 2011, Alexander Best wrote: >> >>> On Thu Dec 22 11, Dimitry Andric wrote: Hi, I would like to ask some feedback on the attached patch, which cleans up the kernel optimization options for amd64. This was touched upon earlier by Alexander Best in freebsd-toolchain, here: >>> >>> i've been using such settings for a few months now and haven't noticed any >>> problems. >>> >>> however bruce evans raised a good point (in a private mail). when you >>> compile a >>> kernel without debugging enabled, -O2 is the default. if you experience >>> issues, >>> and enable debugging, -O0 now becomes the default. in case the problems >>> with >>> the kernel were caused by the -O2 option and aren't present with the -O0 >>> option, the newly built kernel with debugging enabled will not help you >>> fix the >>> problems. in that case you would need to set -O2 explicitly in CFLAGS. his >>> exact words were: >>> >>> " >>> I don't like -O2 for anything. However, if it is only a default, it is >>> not a problem provided it can be canceled easily. And for debugging, you >>> want the default to be the same as without debugging, so that (by default) >>> you debug the same code that caused the problem. >>> " >>> >>> however i don't think this is fixable. using -O0 for debuggable and >>> non-debuggable kernels will cause too much of a slowdown. >>> >>> having -O2 as the default flag for non-debuggable kernels and -O2 -g for >>> debuggable kernels might cause situations, where debugging isn't possible, >>> where with -O0 -g it would have been. >>> >>> so i guess although bruces concerns are valid, they are impossible to >>> solve. >> >> Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2. > > sorry. of course i meant -O: > > .if defined(DEBUG) > _MINUS_O= -O > CTFFLAGS+= -g > .else > [..] Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought.. -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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick wrote: > On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: >> On 12/21/11 19:41, Alexander Leidinger wrote: >>> 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 to see movement ;-) >> >> But there seems something unclear: >> >> man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in >> /etc/make.conf. >> The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. >> >> What's right and what's wrong now? > > I can say with certainty that this value belongs in /etc/make.conf > (on RELENG_8 and earlier at least). > > src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, > so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. Thanks, -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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Am Fri, 23 Dec 2011 02:17:00 +0100 schrieb "O. Hartmann" : > Benchmarks also could lead developers to look into more details of the > weak points of their OS, if they're open for that. Therefore, > benchmarks are very useful. But not if any real fault of the OS is > excused by a faulty becnhmarking. Hi, it is important for the project to be known and I think that the benchmarks made by Phoronix help FreeBSD to gain popularity, even they look bad sometimes. Furthermore, to make a benchmark is a lot of work and the results are useful, because at the end someone will look at it and will try to improve the results. Thank you for investing your time. I remember that I've made some tests with different platforms i386 vs amd64 with simple tools like "openssl speed" some time ago and got some bad results for amd64 that no one cared to explain. These bad results weren't reflected on Linux that I tested later for comparison. And most people have a weird attitude to think that the tester measures wrong instead of taking a look at it. They forget that as a FreeBSD user you would rather see FreeBSD win over Linux. I've seen that Phoronix made various benchmarks about FreeBSD compared to Linux and I can tell you that _subjectively_ the benchmarks reflect what I always thought about FreeBSD. I simply _know_ that FreeBSD is worse in concurrency behavior, I know that it has I/O trouble, I know that it is mostly faster emulating 3D games than Linux runs them natively. I knew this already _before_ you published the benchmark about the 3D performance. I cannot see any evil intentions in these benchmarks. All I can see is the wrong attitude _here_. If anyone thinks that Phoronix makes bad benchmarks, they should do these benchmarks by themselves and publish the results. As long as no one tries, Phoronix stays the best reference for me and for everyone else. And don't forget, benchmarks can never be objective enough and someone will always be mad about the results. Especially, when you present them a "versus battle". A further thing is that I cannot understand the people here sometimes. I would like that the -RELEASE versions of FreeBSD perform well without any further optimizations. When the distribution does not compile with the latest compiler it's simply a bug. Why should one try to penalize the other distribution and downgrade their binaries? When FreeBSD has a bad default setup, there must be a reason for that. Tell me this reason and show me that it's justified in form of some other benchmark. -- Martin signature.asc Description: PGP signature
Re: r228700 can't dhclient em0
On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote: D> > D> So does that mean that if I upgrade to the latest HEAD from a system D> > D> built before the ifconfig changes that when I reboot my network will D> > D> come up? D> > D> > Yes, older infconfig will work in "head < r228571 || head > r228768". D> D> I just tried with r228122 and got the same result. dhclient errors out D> with "can't find em0" although 'ifconfig em0' does produce results. The dhclient issue you faced isn't related to my new CARP commit either my SIOCAIFADDR work. I'm sorry that we flooded your email thread with the discussion. The breakage from r228571 looks like: # ifconfig em0 10.0.0.1 ioctl (SIOCAIFADDR): Invalid argument # The breakage from r228313 looks like: Starting dhclient. ifconfig: ioctl (SIOCAIFADDR): File exists D> I'm also not sure what you meant by "head > r228768" above, since we're D> only up to r228824 in total so far. Maybe your time machine works better D> than mine? :) I don't see any problem. r228824 > r228768, isn't it? -- 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: r228700 can't dhclient em0
On 12/22/2011 23:22, Gleb Smirnoff wrote: > On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote: > D> > D> So does that mean that if I upgrade to the latest HEAD from a system > D> > D> built before the ifconfig changes that when I reboot my network will > D> > D> come up? > D> > > D> > Yes, older infconfig will work in "head < r228571 || head > r228768". > D> > D> I just tried with r228122 and got the same result. dhclient errors out > D> with "can't find em0" although 'ifconfig em0' does produce results. > > The dhclient issue you faced isn't related to my new CARP commit either > my SIOCAIFADDR work. I'm sorry that we flooded your email thread with > the discussion. The breakage from r228571 looks like: > > # ifconfig em0 10.0.0.1 > ioctl (SIOCAIFADDR): Invalid argument > # > > The breakage from r228313 looks like: > > Starting dhclient. > ifconfig: ioctl (SIOCAIFADDR): File exists OK, thanks. > D> I'm also not sure what you meant by "head > r228768" above, since we're > D> only up to r228824 in total so far. Maybe your time machine works better > D> than mine? :) > > I don't see any problem. r228824 > r228768, isn't it? D'oh ... I don't know how I missed that, moving too fast, pulled in too many directions, etc. 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"
