Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hello, Samuel. You wrote 15 декабря 2011 г., 16:32:47: > Other benchmarks in the Phoronix suite and their representations are > similarly flawed, _ALL_ of these results should be ignored and no time > should be wasted by any FreeBSD committer further evaluating this > garbage. (Yes, I have been down this rabbit hole). Here is one problem: we have choice from three items: (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix (communication with them, convincing, that they benchamrks are unfare / meaningless, ets) (3) Lose [potential] userbase. You know, that these benchmarks are bad. I know. But potential (and even some current!) user doesn't. And it seems, that these benchmarks become popular over Internet. -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Hello, Adrian. You wrote 16 декабря 2011 г., 20:43:27: > Guys/girls/fuzzy things - this is 2011; people look at shiny blog > sites with graphs rather than mailing lists. Sorry, we lost that > battle. :) My thoughts exactly. -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/19/11 09:27, Lev Serebryakov wrote: > Hello, Samuel. > You wrote 15 декабря 2011 г., 16:32:47: > >> Other benchmarks in the Phoronix suite and their representations are >> similarly flawed, _ALL_ of these results should be ignored and no time >> should be wasted by any FreeBSD committer further evaluating this >> garbage. (Yes, I have been down this rabbit hole). > Here is one problem: we have choice from three items: > > (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD > > (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix > (communication with them, convincing, that they benchamrks are unfare > / meaningless, ets) > > (3) Lose [potential] userbase. > > You know, that these benchmarks are bad. I know. But potential (and > even some current!) user doesn't. And it seems, that these benchmarks > become popular over Internet. > +1 It is not about a faky way to let a specific OS look good by any means. I'M afraid of (3), which also implies pushing more towards beeing meaningless and not anymore a alternative with a unique, remarkable criteria to be choosen as __the__ operating system of the first choice for several purposes. By the way, how such a development could look alaike is very clear when it comes to GPGPU/HPC, highly related to the availability of proper graphics card drivers, X11 development and the necessary libraries, APIs and even compilers. None of those "professionals" out here, none of those pushing the eyewhitness of bad performance into very deep-insight-talks about what could cause the problem has obviously ever negotiated with people of the "upper floor" when it comes to the choice of the OS. Within my department, the *BSD aren't even considered an option, even if they would perform best for the specified purpose (which, I regeret, is a shrinking basis now since also Linux will have ZFS). Sometimes I feel like Don Quixote, fighting against windmills. Sorry having brought up this thread and I beg for pardon for putting another scrtach into the autoerotic world of the "core". signature.asc Description: OpenPGP digital signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
2011/12/19 Lev Serebryakov : > Hello, Samuel. > You wrote 15 декабря 2011 г., 16:32:47: > >> Other benchmarks in the Phoronix suite and their representations are >> similarly flawed, _ALL_ of these results should be ignored and no time >> should be wasted by any FreeBSD committer further evaluating this >> garbage. (Yes, I have been down this rabbit hole). > Here is one problem: we have choice from three items: > > (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD > > (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix > (communication with them, convincing, that they benchamrks are unfare > / meaningless, ets) > > (3) Lose [potential] userbase. > > You know, that these benchmarks are bad. I know. But potential (and > even some current!) user doesn't. And it seems, that these benchmarks > become popular over Internet. > > -- > // Black Lion AKA Lev Serebryakov > Here is where you completely derail the train, let me paste again what I said before. ... Take the first test as an example, Blogbench read. This doesn't raise any red flags, right? At least not until you realize that Blogbench isn't a read test, it's a read/write test. So what they have done here is run a read/write test and then thrown away the write results for both platforms and reported only the read results. If you dig down into the actual results, http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will see two Blogbench numbers, one for read and another for write. These were both taken from the same Blogbench run, so FreeBSD optimizes writes over reads, that's probably a good thing for your data but a bad thing when someone totally misrepresents benchmark results. ... FreeBSD actually does _BETTER_ (subjectively) in this test than the Linux system when you look at what is really going on. FreeBSD is favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, the benchmarks need to be fixed to represent reality rather than throwing half of the results in the trash. To be quite frank, "fixing" FreeBSD to look good on this benchmark will make it a worse real-world OS. But you guys go ahead and foot-shoot over these ridiculous benchmarks all you want. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Mon, Dec 19, 2011 at 6:49 PM, Samuel J. Greear wrote: > FreeBSD actually does _BETTER_ (subjectively) in this test than the > Linux system when you look at what is really going on. FreeBSD is > favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, > the benchmarks need to be fixed to represent reality rather than > throwing half of the results in the trash. To be quite frank, "fixing" > FreeBSD to look good on this benchmark will make it a worse real-world > OS. But you guys go ahead and foot-shoot over these ridiculous > benchmarks all you want. > Would you prefer a blog which allows you to: A: - create/write 100 posts/s - serve/read 1000 posts/s or B: - create/write 80 posts/s - serve/read 3000 posts/s ? I would personally choose B. -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 19 dec 2011, at 12:50, "Samuel J. Greear" wrote: > 2011/12/19 Lev Serebryakov : >> Hello, Samuel. >> You wrote 15 декабря 2011 г., 16:32:47: >> >>> Other benchmarks in the Phoronix suite and their representations are >>> similarly flawed, _ALL_ of these results should be ignored and no time >>> should be wasted by any FreeBSD committer further evaluating this >>> garbage. (Yes, I have been down this rabbit hole). >> Here is one problem: we have choice from three items: >> >> (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >> >> (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix >> (communication with them, convincing, that they benchamrks are unfare >> / meaningless, ets) >> >> (3) Lose [potential] userbase. >> >> You know, that these benchmarks are bad. I know. But potential (and >> even some current!) user doesn't. And it seems, that these benchmarks >> become popular over Internet. >> >> -- >> // Black Lion AKA Lev Serebryakov >> > > Here is where you completely derail the train, let me paste again what > I said before. > > ... > Take the first test as an example, Blogbench read. This doesn't raise > any red flags, right? At least not until you realize that Blogbench > isn't a read test, it's a read/write test. So what they have done here > is run a read/write test and then thrown away the write results for > both platforms and reported only the read results. If you dig down > into the actual results, > http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will > see two Blogbench numbers, one for read and another for write. These > were both taken from the same Blogbench run, so FreeBSD optimizes > writes over reads, that's probably a good thing for your data but a > bad thing when someone totally misrepresents benchmark results. > ... > > FreeBSD actually does _BETTER_ (subjectively) in this test than the > Linux system when you look at what is really going on. FreeBSD is > favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, > the benchmarks need to be fixed to represent reality rather than > throwing half of the results in the trash. To be quite frank, "fixing" > FreeBSD to look good on this benchmark will make it a worse real-world > OS. But you guys go ahead and foot-shoot over these ridiculous > benchmarks all you want. > > Sam > I seem to remember that before ULE people were fleeing to Linux as the os to run apache on since 4BSD didn't scale all too well. That may have changed over time though. However ULE could perhaps be made aware technologies like turbo-boost, ie with few threads higher performance might be gained by utilizing all virtual cores on a physical core before spreading tasks to too different cores. Just my speculations though :) Regards Andreas Nilsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
IMHO, no offence, as always. As were told, Phoronix used "default" setup, not tuned. So? Is average user will tune it after setup? No, he'll get same defaults, and would expect same performance as in tests, and he probably get it. The problem of FreeBSD is not it's default settings, some kind of very-safe defaults really should be there. But problem really is lacking of choosing them (defaults) during install, for average users. For example, few checkboxes with common sysctl tuning would be perfect, even if they would be marked as "Experimental", or not recommended. I'm thinking it's better way to make something in one place (like in installer) rather than require make almost same actions in many (hundreds of thousands?... more?...) places (end-users forced to read mail-lists/handbooks/forums over and over for same solutions). Simple example - many connections for PostgreSQL is not available on FreeBSD out-of-box. Just google "postgresql freebsd max connection" and you'll see how many there bikesheds requested and same solutions posted again and again :) FreeBSD currently have very obscure, closed community. To get in touch, you need to subscribe to several mail lists, constantly read them, I've just found recently (my shame of course) in mail list that there is service ( pub.allbsd.org) which constantly building current versions. This is great, but at homepage of freebsd.org there is no word about it :) I hope we all do something good about this, and things will going to change. -- Regards, Alexander Yerenkow ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/19/11 13:21, Andreas Nilsson wrote: > On 19 dec 2011, at 12:50, "Samuel J. Greear" wrote: > >> 2011/12/19 Lev Serebryakov : >>> Hello, Samuel. >>> You wrote 15 декабря 2011 г., 16:32:47: >>> Other benchmarks in the Phoronix suite and their representations are similarly flawed, _ALL_ of these results should be ignored and no time should be wasted by any FreeBSD committer further evaluating this garbage. (Yes, I have been down this rabbit hole). >>> Here is one problem: we have choice from three items: >>> >>> (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >>> >>> (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix >>> (communication with them, convincing, that they benchamrks are unfare >>> / meaningless, ets) >>> >>> (3) Lose [potential] userbase. >>> >>> You know, that these benchmarks are bad. I know. But potential (and >>> even some current!) user doesn't. And it seems, that these benchmarks >>> become popular over Internet. >>> >>> -- >>> // Black Lion AKA Lev Serebryakov >>> >> >> Here is where you completely derail the train, let me paste again what >> I said before. >> >> ... >> Take the first test as an example, Blogbench read. This doesn't raise >> any red flags, right? At least not until you realize that Blogbench >> isn't a read test, it's a read/write test. So what they have done here >> is run a read/write test and then thrown away the write results for >> both platforms and reported only the read results. If you dig down >> into the actual results, >> http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will >> see two Blogbench numbers, one for read and another for write. These >> were both taken from the same Blogbench run, so FreeBSD optimizes >> writes over reads, that's probably a good thing for your data but a >> bad thing when someone totally misrepresents benchmark results. >> ... >> >> FreeBSD actually does _BETTER_ (subjectively) in this test than the >> Linux system when you look at what is really going on. FreeBSD is >> favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, >> the benchmarks need to be fixed to represent reality rather than >> throwing half of the results in the trash. To be quite frank, "fixing" >> FreeBSD to look good on this benchmark will make it a worse real-world >> OS. But you guys go ahead and foot-shoot over these ridiculous >> benchmarks all you want. >> >> Sam >> > > I seem to remember that before ULE people were fleeing to Linux as the > os to run apache on since 4BSD didn't scale all too well. That may > have changed over time though. > > However ULE could perhaps be made aware technologies like turbo-boost, > ie with few threads higher performance might be gained by utilizing > all virtual cores on a physical core before spreading tasks to too > different cores. > > Just my speculations though :) > > Regards > Andreas Nilsson Such a scheduling stratey is definitely necessary on AMDs new "Bulldozer" architecture, which seems to be very pitty about threads locked on the same module. Microsoft just offered a patch for Windows 7 to implant such a "Bulldozer" awarenes but they withdraw the patch as invalid two days after the release. The seults seem to favour FPU performance over integer performance. As Samuel Greear wrote, FreeBSD looks not that bad in some of the benchmarks but there are obviosly issues, at least the fact that Phoronix/openbenchmark.org are the only sites offering benchmarks at all. People outside the FreeBSD realm looking for opportunities, what do you think they will look first after? Phoronix/Openbenchmark.org made the first step and they seem to make FreeBSD look bad (in my opinion), whether righteous or not. Compared to several subjective impressions I have in our heterogeneous environment at the lab, Linux on the same hardware looks in several aspects much better. Oliver signature.asc Description: OpenPGP digital signature
Re: SCHED_ULE should not be the default
В Sat, 17 Dec 2011 23:13:16 +0200 Andriy Gapon пишет: > on 17/12/2011 19:33 George Mitchell said the following: > > Summing up for the record, in my original test: > > 1. It doesn't matter whether X is running or not. > > 2. The problem is not limited to two or fewer CPUs. (It also > > happens for me on a six-CPU system.) > > 3. It doesn't require nCPU + 1 compute-bound processes, just nCPU. > > > > With nCPU compute-bound processes running, with SCHED_ULE, any other > > process that is interactive (which to me means frequently waiting > > for I/O) gets ABYSMAL performance -- over an order of magnitude > > worse than it gets with SCHED_4BSD under the same conditions. > > I definitely do not see anything like this. > Specifically: > - with X > - with 2 CPUs > - with nCPU and/or nCPU + 1 compute-bound processes > - with SCHED_ULE obviously :-) > I do not get "abysmal" performance for I/O active tasks. > > Perhaps there is something specific that you would want me to run and > measure. > Well, share your experiences - what to do, what would the others were fine with SCHED_ULE. ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
on 19/12/2011 19:46 Ivan Klymenko said the following: > В Sat, 17 Dec 2011 23:13:16 +0200 > Andriy Gapon пишет: > >> on 17/12/2011 19:33 George Mitchell said the following: >>> Summing up for the record, in my original test: >>> 1. It doesn't matter whether X is running or not. >>> 2. The problem is not limited to two or fewer CPUs. (It also >>> happens for me on a six-CPU system.) >>> 3. It doesn't require nCPU + 1 compute-bound processes, just nCPU. >>> >>> With nCPU compute-bound processes running, with SCHED_ULE, any other >>> process that is interactive (which to me means frequently waiting >>> for I/O) gets ABYSMAL performance -- over an order of magnitude >>> worse than it gets with SCHED_4BSD under the same conditions. >> >> I definitely do not see anything like this. >> Specifically: >> - with X >> - with 2 CPUs >> - with nCPU and/or nCPU + 1 compute-bound processes >> - with SCHED_ULE obviously :-) >> I do not get "abysmal" performance for I/O active tasks. >> >> Perhaps there is something specific that you would want me to run and >> measure. >> > > Well, share your experiences - what to do, what would the others were > fine with SCHED_ULE. ;) I didn't have to do anything special, so I am at loss as what to share. It just works (tm) for me. Sorry. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fsck_ufs out of swapspace
Problem solved - it was indeed an endian thing. The problem is that fsck uses a real_dev_bsize variable that is declared long, but the DIOCGSECTORSIZE ioctl takes an u_int argument. A PR has been submitted. Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Mon Dec 19 11, Nathan Whitehorn wrote: > On 12/18/11 04:34, Adrian Chadd wrote: > >The trouble is that there's lots of anecdotal evidence, but noone's > >really gone digging deep into _their_ example of why it's broken. The > >developers who know this stuff don't see anything wrong. That hints to > >me it may be something a little more creepy - as an example, the > >interplay between netisr/swi/taskqueue/callbacks and such. It may be > >that something is being starved that isn't obviously obvious. It's > >just a stab in the dark, but it sounds somewhat plausible based on > >what I've seen ULE do in my network throughput hacking. > > > >I applaud reppie for trying to make it as easy as possible for people > >to use KTR to provide scheduler traces for him to go digging with, so > >please, if you have these issues and you can absolutely reproduce > >them, please follow his instructions and work with him to get him what > >he needs. > > The thing I've seen is that ULE is substantially more enthusiastic about > migrating processes between cores than 4BSD. Often, this is a good > thing, but can increase the rate of cache misses, hurting performance > for cache-bound processes (I see this particularly in HPC-type > scientific workloads). It might be interesting to add some kind of > tunable here. does r228718 have any impact regarding this behaviour? cheers. alex > > Another more interesting and slightly longer-term possibility if someone > wants a project would be to integrate scheduling decisions with hwpmc > counters, to accumulate statistics on cache hits at each context switch > and preferentially keep processes with a high hits/misses ratio on the > same thread/cache domain relative to processes with a low one. > -Nathan > > P.S. The other thing that could be very interesting from a research and > scheduling standpoint would be to integrate heterogeneous SMP support > into the operating system, with a FreeBSD-4 "Application Processor" > syscall model. We seem to be going down the road where GPGPU computing > has MMUs, timer interrupts, IPIs, etc. (the next AMD Fusions, IBM Cell). > This is something that no operating system currently supports well, and > would be a place for BSD to shine. If anyone has a free graduate student... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fsck_ufs out of swapspace
On 2011-Dec-19 22:27:49 +0100, Michiel Boland wrote: >Problem solved - it was indeed an endian thing. >The problem is that fsck uses a real_dev_bsize variable that is declared long, >but the DIOCGSECTORSIZE ioctl takes an u_int argument. To be accurate, this isn't an endian problem, it's a general problem of passing a pointer to an incorrectly sized object. The bug is masked on amd64 & iA64 because real_dev_bsize is statically allocated and therefore initialised to zero. This means the failure to assign the top 32 bits in the ioctl doesn't affect the final result. >A PR has been submitted. sparc64/163460 for the record. Thank you for tracking that down. -- Peter Jeremy pgp7m3HL1diGx.pgp Description: PGP signature
