Re: Remove debug echo
Garrett, On Thu, Dec 15, 2011 at 10:39 AM, Garrett Cooper wrote: >> If someone would please, PLEASE commit this.. I will give you beer, or > >> wine, or a copy of Skyrim, or a few months subscription to WoW, or > >> something else of value to you that we could negotiate :)... I'm quite > >> frankly tired of having to playing guessing games fishing through logs > >> trying to determine build errors on FreeBSD if and when they do occur > >> with pmake, and I'm sure that a number of developers and build/release > >> engineers out there are in the same boat as I am. > > > > > > Can you explain why did you remove MESSAGE() invocations in your patch? > > Other than that the patch looks good to me. > > I thought that printing out MESSAGE and the more informative > *printf was kind of redundant. > Thanks! > -Garrett > > PS A sidenote why I bypassed MESSAGE(..): if I used the macro, make > would segfault as MESSAGE depends on targFmt and targPrefix being set > to something sane (they both default to NULL -- one explicitly, the > other implicitly because it's in the .BSS). These vars are only set in > one section of code, but I took the easy route out to avoid > accidentally breaking other code paths and because what I did in the > previously attached patch was simple to implement and test. > I did not mean that you should use MESSAGE() for your purposes, but removing existing "invocations" seems to be unnecessary. Max ___ 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.1Server
- Original Message - From: "Michael Larabel" I was the on that carried out the testing and know that it was on the same system. All of the testing, including the system tables, is fully automated. Under FreeBSD sometimes the parsing of some component strings isn't as nice as Linux and other supported operating systems by the Phoronix Test Suite. For the BSD motherboard string parsing it's grabbing hw.vendor/hw.product from sysctl. Is there a better place to read the motherboard DMI information from? dmidecode may provide better info? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Am 15.12.2011 11:10, schrieb Michael Larabel: > No, the same hardware was used for each OS. > > In terms of the software, the stock software stack for each OS was used. Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with journaling enabled) should be an obvious choice since it is more similar in concept to ext4 and since that is what most FreeBSD users will use with FreeBSD? Did you tune the ZFS ARC (e.g. vfs.zfs.arc_max="6G") for the tests? And BTW: Did your measured run times account for the effect, that Linux keeps much more dirty data in the buffer cache (FreeBSD has a low limit on dirty buffers since under realistic load the already cached data is much more likely to be reused and thus more valuable than freshly written data; aggressively caching dirty data would significantly reduce throughput and responsiveness under high load). Given the hardware specs of the test system, I guess that Linux accepts at least 100 times the dirty data in the buffer cache, compared to FreeBSD (where this number is at most in the tens of megabyte range). If you did not, then your results do not represent a server load (which I'd expect relevant, if you are testing against Oracle Linux 6.1 server), where continuous performance is required. Tests that run on an idle system starting in a clean state and ignoring background flushing of the buffer cache after the timed program has stopped are perhaps useful for a very lowly loaded PC, but not for a system with high load average as the default. I bet that if you compared the systems under higher load (which admittedly makes it much harder to get sensible numbers for the program under test) or with reduced buffer cache size (or raise the dirty buffer limit in FreeBSD accordingly, which ought to be possible with sysctl and/or boot time tuneables, e.g. "vfs.hidirtybuffers"). And a last remark: Single benchmark runs do not provide reliable data. FreeBSD comes with "ministat" to check the significance of benchmark results. Each test should be repeated at least 5 times for meaningful averages with acceptable confidence level. 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
On Dec 15, 2011, at 3:48 PM, Jeremy Chadwick wrote: […] > That said: thrown out, data ignored, done. > > Now what? Where are we? We're right back where we were a day or two > ago; meaning no closer to solving the dilemma reported by users and > SCHED_ULE. Heck, we're not even sure if there is an issue, other than > some folks confirming that SCHED_4BSD performs better for them (that's > what started this whole thread), and there are at least a couple which > have stated this. But, are any of these benchmarks really engaging the 4BSD/ULE scheduler differences? Most such benchmarks are run on a system with no other load whatsoever and in no way represent real world experience. What is more, I believe in such benchmarks "the system feels sluggish" is not measured at all. Even if it is measured, if in such case the benchmark finishes "better" - that is, faster, or say, makes the system freeze for the user for the duration of the test -- it will be considered "win", because the benchmark suite ran faster on that particular system -- whereas a system which ran the benchmark fast, provided good interactive response etc would be considered "loser". I think it is not good idea to hijack this thread, but instead focusing on the other SCHED_ULE bashing thread to define an reasonable benchmark or a set of benchmarks rather -- so that many would run it and provide feedback. 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 Dec 15, 2011, at 3:25 PM, Stefan Esser wrote: > Am 15.12.2011 11:10, schrieb Michael Larabel: >> No, the same hardware was used for each OS. >> >> In terms of the software, the stock software stack for each OS was used. > > Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with > journaling enabled) should be an obvious choice since it is more similar > in concept to ext4 and since that is what most FreeBSD users will use > with FreeBSD? Or perhaps, since it is "server" Linux distribution, use ZFS on Linux as well. With identical tuning on both Linux and FreeBSD. Having the same FS used by both OS will help make the comparison more sensible for FS I/O. 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
15.12.2011 17:36, Michael Larabel пишет: On 12/15/2011 07:25 AM, Stefan Esser wrote: Am 15.12.2011 11:10, schrieb Michael Larabel: No, the same hardware was used for each OS. In terms of the software, the stock software stack for each OS was used. Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with journaling enabled) should be an obvious choice since it is more similar in concept to ext4 and since that is what most FreeBSD users will use with FreeBSD? I was running some ZFS vs. UFS tests as well and this happened to have ZFS on when I was running some other tests. Can we look at the tests? My opinion is ZFS without tuning is much slower than UFS2. ___ 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
15.12.2011 15:48, Jeremy Chadwick wrote: I'm getting to the point where I'm considering formulating a private mail to Jeff Roberson, requesting that he be aware of the discussion that's happening (not that he necessarily follow or read it), and that based on what I can tell we're at a roadblock -- nobody so far is absolutely certain how to "benchmark" and compare ULE vs. 4BSD in multiple ways, so that those of us involved here can run such utilities and provide the data somewhere central for devs to review. I only mention this because so far I haven't seen anyone really say "okay, this is what we should be using for these kinds of tests". Yay nature of the beast. I'll try to summarize and propose a test scenario. I don't know whether this helps or not. We should have two different task types for this one. The first would be Super Affine tasks. They should use few to none syscalls, use medium math, have low memory footprint. No syscalls means this tasks will never stop for memory/disk or other activity so each time the queue is looked upon this task will be ready to run. Medium math means this shouldn't be just a simple big loop so that processor will really compute something with this data. Low memory footprint means this task can reside with data on CPU L1 cache for eons. I'm not sure about branch prediction, should it be distorted or not... The other task type would be Worker. It doesn't matter what it does but it agressively uses syscalls like working with files/directories. There should be at least one SA-task per core and at least 10 (?) W-tasks per core. -- Sphinx of black quartz judge my vow. ___ 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
Op 15-12-2011 8:32, O. Hartmann schreef: Just saw this shot benchmark on Phoronix dot com today: http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzA It may be worth to discuss the sad performance of FBSD in some parts of the benchmark. A difference of a factor 10 or 100 is simply far beyond disapointing, it is more than inacceptable and by just reading those benchmarks, I'd like to drop thinking of using FreeBSD even as a backend server in scientific and business environments. In detail, some of the SciMark benches look disappointing. The overall image can't help over the fact that in C-Ray FreeBSD is better performing. From the compiler, I'd like say there couldn't be a drop of more than 10 - 15% in performance - but not 10 or 100 times. I'm just thinking about the discussion of SCHED_ULE and all the saur spots we discussed when I stumbled over the test. Regards, Oliver Detailed results here: http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 As usual, the phoronix benchmarks are very misleading. 1) The linked benchmarks were not run on the same hardware. Hardware is close but not completely equal; for instance different brands of disks were used. 2) They didn't use the same compiler. This is really bad and _can_ lead to more than a factor 2 performance difference. Especially in "scientific" programs where (auto) vectorization is very important. Why on earth the benchmarker was too lazy to install a more recent GCC I have no idea. Of all the benchmarks shown only the disk benchmarks are interesting, because they actually stress the system. Unfortunately they screwed that up too because they were performed on ZFS instead of the default, plain UFS which is a lot more like EXT4 in terms of functionality. The rest are pure CPU bound userspace workloads and I bet that if they were performed using the same compiler, similar results would've been achieved (barring any major VM differences). In any case we would've been able to actually compare FreeBSD vs Oracle Linux instead of GCC 4.5 vs 4.2. Now they are useless. I'm sorry if this mail sounds a bit harsh but I'm tired of seeing phoronix making the same elementary mistakes again and again even after these have been pointed out years ago. - Pieter ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
2011/12/14 Mike Tancsa : > On 12/13/2011 7:01 PM, m...@freebsd.org wrote: >> >> Has anyone experiencing problems tried to set sysctl >> kern.sched.steal_thresh=1 ? >> >> I don't remember what our specific problem at $WORK was, perhaps it >> was just interrupt threads not getting serviced fast enough, but we've >> hard-coded this to 1 and removed the code that sets it in >> sched_initticks(). The same effect should be had by setting the >> sysctl after a box is up. > > FWIW, this does impact the performance of pbzip2 on an i7. Using a 1.1G file > > pbzip2 -v -c big > /dev/null > > with burnP6 running in the background, > > sysctl kern.sched.steal_thresh=1 > vs > sysctl kern.sched.steal_thresh=3 > > > > N Min Max Median Avg Stddev > x 10 38.005022 38.42238 38.194648 38.165052 0.15546188 > + 9 38.695417 40.595544 39.392127 39.435384 0.59814114 > Difference at 95.0% confidence > 1.27033 +/- 0.412636 > 3.32852% +/- 1.08119% > (Student's t, pooled s = 0.425627) > > a value of 1 is *slightly* faster. Hi Mike, was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE? Also, the results here should be in the 3% interval for the avg case, which is not yet at the 'alarm level' but could still be an indication. I still suspect I/O plays a big role here, however, thus it could be detemined by other factors. Could you retry the bench checking CPU usage and possible thread migration around for both cases? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
2011/12/13 Jeremy Chadwick :
> On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> > issue. And yes, there are cases where SCHED_ULE shows much better
>> > performance then SCHED_4BSD. [...]
>>
>> Do we have any proof at hand for such cases where SCHED_ULE performs
>> much better than SCHED_4BSD? Whenever the subject comes up, it is
>> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
>> 2. But in the end I see here contradictionary statements. People
>> complain about poor performance (especially in scientific environments),
>> and other give contra not being the case.
>>
>> Within our department, we developed a highly scalable code for planetary
>> science purposes on imagery. It utilizes present GPUs via OpenCL if
>> present. Otherwise it grabs as many cores as it can.
>> By the end of this year I'll get a new desktop box based on Intels new
>> Sandy Bridge-E architecture with plenty of memory. If the colleague who
>> developed the code is willing performing some benchmarks on the same
>> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
>> recent Suse. For FreeBSD I intent also to look for performance with both
>> different schedulers available.
>
> This is in no way shape or form the same kind of benchmark as what
> you're planning to do, but I thought I'd throw it out there for folks to
> take in as they see fit.
>
> I know folks were focused mainly on buildworld.
>
> I personally would find it interesting if someone with a higher-end
> system (e.g. 2 physical CPUs, with 6 or 8 cores per CPU) was to do the
> same test (changing -jX to -j{numofcores} of course).
>
> --
> | Jeremy Chadwick jdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, US |
> | Making life hard for others since 1977. PGP 4BD6C0CB |
>
>
> sched_ule
> ===
> - time make -j2 buildworld
> 1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io 4565pf+0w
> - time make -j2 buildkernel
> 640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w
>
>
> sched_4bsd
>
> - time make -j2 buildworld
> 1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io 6451pf+0w
> - time make -j2 buildkernel
> 638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w
>
>
> software
> ==
> * sched_ule test: FreeBSD 8.2-STABLE, Thu Dec 1 04:37:29 PST 2011
> * sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST 2011
Hi Jeremy,
thanks for the time you spent on this.
However, I wanted to ask/let you note 3 things:
1) Did you use 2 different code base for the test? (one updated on
December 1 and another one on December 12)
2) Please note that you should have repeated this test several times
(basically until you don't get a standard deviation which is
acceptable with ministat) and report the ministat output
3) The difference is less than 2% which I suspect is really
statistically unuseful/the same
I'm not really even surprised ULE is not faster than 4BSD in this case
because usually buildworld/buildkernel tests are driven for the vast
majority by I/O overhead rather than scheduler capacity. It would be
more interesting to analyze how buildworld does while another type of
workload is going on.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On 12/15/2011 11:26 AM, Attilio Rao wrote: > > Hi Mike, > was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE? Hi Attilio, It was the same codebase. > Could you retry the bench checking CPU usage and possible thread > migration around for both cases? I can, but how do I do that ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: SCHED_ULE should not be the default
2011/12/15 Mike Tancsa : > On 12/15/2011 11:26 AM, Attilio Rao wrote: >> >> Hi Mike, >> was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE? > > Hi Attilio, > It was the same codebase. > > >> Could you retry the bench checking CPU usage and possible thread >> migration around for both cases? > > I can, but how do I do that ? I'm thinking now to a better test-case for this: can you try that on a tmpfs volume? Also what filesystem you were using? How many CPUs were in place? Did you reboot before to move the steal_thresh value? Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On 12/15/2011 11:42 AM, Attilio Rao wrote: > > I'm thinking now to a better test-case for this: can you try that on a > tmpfs volume? There is enough RAM in the box so that it should not touch the disk, and I was sending the output to /dev/null, so it was not writing to the disk. > > Also what filesystem you were using? UFS > How many CPUs were in place? 4 > Did you reboot before to move the steal_thresh value? No. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: SCHED_ULE should not be the default
2011/12/15 Mike Tancsa : > On 12/15/2011 11:42 AM, Attilio Rao wrote: >> >> I'm thinking now to a better test-case for this: can you try that on a >> tmpfs volume? > > There is enough RAM in the box so that it should not touch the disk, and > I was sending the output to /dev/null, so it was not writing to the disk. > >> >> Also what filesystem you were using? > > UFS > >> How many CPUs were in place? > > 4 > >> Did you reboot before to move the steal_thresh value? > > No. So, as very first thing, can you try the following: - Same codebase, etc. etc. - Make the test 4 times, discard the first and ministat for the other 3 - Reboot - Change the steal_thresh value - Make the test 4 times, discard the first and ministat for the other 3 Then report discarded values and the ministated one and we will have more informations I guess (also, I don't think devfs contention should play a role here, thus nevermind about it for now). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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 12/15/11 14:51, schrieb Daniel Kalchev: > > On Dec 15, 2011, at 3:25 PM, Stefan Esser wrote: > >> Am 15.12.2011 11:10, schrieb Michael Larabel: >>> No, the same hardware was used for each OS. >>> >>> In terms of the software, the stock software stack for each OS was used. >> >> Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with >> journaling enabled) should be an obvious choice since it is more similar >> in concept to ext4 and since that is what most FreeBSD users will use >> with FreeBSD? > > > Or perhaps, since it is "server" Linux distribution, use ZFS on Linux as > well. With identical tuning on both Linux and FreeBSD. Having the same FS > used by both OS will help make the comparison more sensible for FS I/O. > > Daniel___ Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it is legitimate to compare ZFS and ext4. It would be much more competetive to compare Linux BTRFS and FreeBSD ZFS. Each OS does optimize on different filesystems and a user/manager can assume that the vendor offers the best performance available by turning on the default FS by a standard stock installation. Using ZFS on Linux would be a great disadvantage and the benchmark would turn out the same bullsh... as comparing Linux-domain only with FreeBSD weknesses only ... Linux distributions offer setups for desktop and server. The FreeBSD folks have the choice to do it themselfes. And maybe I'm one of those puritain people appreciating this. "Out of the box" OS is Windooze, with all its consequences. Oliver Post scriptum: It seems to be hard to follow the benchmark environment on Phoronix since the URL refers to a setup of different systems. signature.asc Description: OpenPGP digital signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Am 12/15/11 14:58, schrieb Daniel Kalchev: > > On Dec 15, 2011, at 3:48 PM, Jeremy Chadwick wrote: > > […] >> That said: thrown out, data ignored, done. >> >> Now what? Where are we? We're right back where we were a day or two >> ago; meaning no closer to solving the dilemma reported by users and >> SCHED_ULE. Heck, we're not even sure if there is an issue, other than >> some folks confirming that SCHED_4BSD performs better for them (that's >> what started this whole thread), and there are at least a couple which >> have stated this. > > But, are any of these benchmarks really engaging the 4BSD/ULE scheduler > differences? Most such benchmarks are run on a system with no other load > whatsoever and in no way represent real world experience. > > What is more, I believe in such benchmarks "the system feels sluggish" is not > measured at all. Even if it is measured, if in such case the benchmark > finishes "better" - that is, faster, or say, makes the system freeze for the > user for the duration of the test -- it will be considered "win", because the > benchmark suite ran faster on that particular system -- whereas a system > which ran the benchmark fast, provided good interactive response etc would be > considered "loser". I guess you have some proofs on that "feeling"? > > I think it is not good idea to hijack this thread, but instead focusing on > the other SCHED_ULE bashing thread to define an reasonable benchmark or a set > of benchmarks rather -- so that many would run it and provide feedback. > > > Daniel___ signature.asc Description: OpenPGP digital signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Thu, Dec 15, 2011 at 9:58 AM, O. Hartmann wrote: > Am 12/15/11 14:51, schrieb Daniel Kalchev: >> >> On Dec 15, 2011, at 3:25 PM, Stefan Esser wrote: >> >>> Am 15.12.2011 11:10, schrieb Michael Larabel: No, the same hardware was used for each OS. In terms of the software, the stock software stack for each OS was used. >>> >>> Just curious: Why did you choose ZFS on FreeBSD, while UFS2 (with >>> journaling enabled) should be an obvious choice since it is more similar >>> in concept to ext4 and since that is what most FreeBSD users will use >>> with FreeBSD? >> >> >> Or perhaps, since it is "server" Linux distribution, use ZFS on Linux as >> well. With identical tuning on both Linux and FreeBSD. Having the same FS >> used by both OS will help make the comparison more sensible for FS I/O. >> >> Daniel___ > > Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it > is legitimate to compare ZFS and ext4. It would be much more competetive > to compare Linux BTRFS and FreeBSD ZFS. There is a separate kernel module for ZFS that can be installed, giving you proper kernel-level support for ZFS on Linux. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
Am 12/15/11 15:20, schrieb Steven Hartland: > With all the discussion I thought I'd give a buildworld > benchmark a go here on a spare 24 core machine. ULE > tested fine but with 4BSD it wont even boot panicing > with the following:- > http://screensnapr.com/v/hwysGV.png > > This is on a clean 8.2-RELEASE-p4 > > Upgrading to RELENG_9 fixed this but its a bit concerning > that just changing the scheduler would cause the machine > to panic on boot. > > Its only a single run so varience could be high but here's > the result of a buildworld on this machine running the > two different schedulers:- > 4BSD: 24m54.10s real 2h43m12.42s user 56m20.07s sys > ULE: 23m54.68s real 2h34m59.04s user 50m59.91s sys > > What really sticks out is that this is over double that > of an 8.2 buildworld on the same machine with the same > kernel > ULE: 11m12.76s real 1h27m59.39s user 28m59.57s sys > > This was run 9.0-PRERELEASE kernel due to 4BSD panicing > on boot under 8.2. > > So for this use ULE vs 4BSD is neither here-nor-there > but 9.0 buildworld is very slow (x2 slower) compared > with 8.2 so whats a bigger question in my mind. > >Regards >Steve > All of our 8.2-STABLE with ncpu >= 4 compile the OS in half the time a compilation of FreeBSD 9/10 is needed to. I guess this is due to the huge LLVM contribution which is now part of the source tree. Even if you allow building a whole LLVM suite (and not even pieces of it as in FreeBSD standard for CLANG purposes), it takes another q0 to 20 minutes, depending on the architecture of the underlying host. Building kernel or worl, taking time and show then the invers of that number isn't a good idea, in my opinion. Therefore I like "artificial" benchmarks: have a set of programs that can be compiled and take the time if compilation time is important. Well, your one-shot test would show, that there is indeed a marginal advantage of SCHED_ULE, if the number of cores is big enough (as said to be n > 2 in this thread). But I'm a bit disappointed about the very small advantage on that 24 core hog. Oliver signature.asc Description: OpenPGP digital signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 15 December 2011 17:58, O. Hartmann wrote: > Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it > is legitimate to compare ZFS and ext4. It would be much more competetive > to compare Linux BTRFS and FreeBSD ZFS. > Er... does ext4 guarantee data integrity? You're not comparing like with like; please do some research on the point of ZFS before asserting that they're fair comparisons. A fair(er) comparison could be ext4 with UFS+soft-updates. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
2011/12/15 Jeremy Chadwick :
> On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
>> 2011/12/13 Jeremy Chadwick :
>> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
>> >> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> >> > issue. And yes, there are cases where SCHED_ULE shows much better
>> >> > performance then SCHED_4BSD. ??[...]
>> >>
>> >> Do we have any proof at hand for such cases where SCHED_ULE performs
>> >> much better than SCHED_4BSD? Whenever the subject comes up, it is
>> >> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
>> >> 2. But in the end I see here contradictionary statements. People
>> >> complain about poor performance (especially in scientific environments),
>> >> and other give contra not being the case.
>> >>
>> >> Within our department, we developed a highly scalable code for planetary
>> >> science purposes on imagery. It utilizes present GPUs via OpenCL if
>> >> present. Otherwise it grabs as many cores as it can.
>> >> By the end of this year I'll get a new desktop box based on Intels new
>> >> Sandy Bridge-E architecture with plenty of memory. If the colleague who
>> >> developed the code is willing performing some benchmarks on the same
>> >> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
>> >> recent Suse. For FreeBSD I intent also to look for performance with both
>> >> different schedulers available.
>> >
>> > This is in no way shape or form the same kind of benchmark as what
>> > you're planning to do, but I thought I'd throw it out there for folks to
>> > take in as they see fit.
>> >
>> > I know folks were focused mainly on buildworld.
>> >
>> > I personally would find it interesting if someone with a higher-end
>> > system (e.g. 2 physical CPUs, with 6 or 8 cores per CPU) was to do the
>> > same test (changing -jX to -j{numofcores} of course).
>> >
>> > --
>> > | Jeremy Chadwick ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??jdc at
>> > parodius.com |
>> > | Parodius Networking ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
>> > http://www.parodius.com/ |
>> > | UNIX Systems Administrator ?? ?? ?? ?? ?? ?? ?? ?? ?? Mountain View, CA,
>> > US |
>> > | Making life hard for others since 1977. ?? ?? ?? ?? ?? ?? ?? PGP
>> > 4BD6C0CB |
>> >
>> >
>> > sched_ule
>> > ===
>> > - time make -j2 buildworld
>> > ??1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io 4565pf+0w
>> > - time make -j2 buildkernel
>> > ??640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w
>> >
>> >
>> > sched_4bsd
>> >
>> > - time make -j2 buildworld
>> > ??1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io 6451pf+0w
>> > - time make -j2 buildkernel
>> > ??638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w
>> >
>> >
>> > software
>> > ==
>> > * sched_ule test: ??FreeBSD 8.2-STABLE, Thu Dec ??1 04:37:29 PST 2011
>> > * sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST 2011
>>
>> Hi Jeremy,
>> thanks for the time you spent on this.
>>
>> However, I wanted to ask/let you note 3 things:
>> 1) Did you use 2 different code base for the test? (one updated on
>> December 1 and another one on December 12)
>
> No; src-all (/usr/src on this system) was not updated between December
> 1st and December 12th PST. I do believe I updated it today (15th PST).
> I can/will obviously hold off so that we have a consistent code base for
> comparing numbers between schedulers during buildworld and/or
> buildkernel.
>
>> 2) Please note that you should have repeated this test several times
>> (basically until you don't get a standard deviation which is
>> acceptable with ministat) and report the ministat output
>
> This is the first time I have heard of ministat(1). I'm pretty sure I
> see what it's for and how it applies to this situation, but boy that man
> page could use some clarification (I have 3 people looking at this thing
> right now trying to figure out what means what in the graph :-) ).
> Anyway, graph or not, I see the point.
>
> Regarding multiple tests: yup, you're absolutely right, the only way to
> do it would be to run a sequence of tests repeatedly (probably 10 per
> scheduler). Reboots and rm -fr /usr/obj/* would be required after each
> test too, to guarantee empty kernel caches (of all types) consistently
> every time.
>
> What I posted was supposed to give people just a "general idea" if there
> was any gigantic difference between the two, and there really isn't.
> But, as others have stated (and you below), buildworld may not be an
> effective way to "benchmark" what we're trying to test.
>
> Hence me wondering exactly what would make for a good test. Example:
>
> 1. Run + background some program that "beats on things" (I really don't
> know what; creation/deletion of threads? CPU benchmark? bonnie++?),
> with output going to /dev/null.
> 2. Run + background "time make -j2 buildworld" with output going to /dev/null
> 3. Record/save output fr
Re: SCHED_ULE should not be the default
В Thu, 15 Dec 2011 20:02:44 +0100
Attilio Rao пишет:
> 2011/12/15 Jeremy Chadwick :
> > On Thu, Dec 15, 2011 at 05:26:27PM +0100, Attilio Rao wrote:
> >> 2011/12/13 Jeremy Chadwick :
> >> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:
> >> >> > Not fully right, boinc defaults to run on idprio 31 so this
> >> >> > isn't an issue. And yes, there are cases where SCHED_ULE
> >> >> > shows much better performance then SCHED_4BSD. ??[...]
> >> >>
> >> >> Do we have any proof at hand for such cases where SCHED_ULE
> >> >> performs much better than SCHED_4BSD? Whenever the subject
> >> >> comes up, it is mentioned, that SCHED_ULE has better
> >> >> performance on boxes with a ncpu > 2. But in the end I see here
> >> >> contradictionary statements. People complain about poor
> >> >> performance (especially in scientific environments), and other
> >> >> give contra not being the case.
> >> >>
> >> >> Within our department, we developed a highly scalable code for
> >> >> planetary science purposes on imagery. It utilizes present GPUs
> >> >> via OpenCL if present. Otherwise it grabs as many cores as it
> >> >> can. By the end of this year I'll get a new desktop box based
> >> >> on Intels new Sandy Bridge-E architecture with plenty of
> >> >> memory. If the colleague who developed the code is willing
> >> >> performing some benchmarks on the same hardware platform, we'll
> >> >> benchmark bot FreeBSD 9.0/10.0 and the most recent Suse. For
> >> >> FreeBSD I intent also to look for performance with both
> >> >> different schedulers available.
> >> >
> >> > This is in no way shape or form the same kind of benchmark as
> >> > what you're planning to do, but I thought I'd throw it out there
> >> > for folks to take in as they see fit.
> >> >
> >> > I know folks were focused mainly on buildworld.
> >> >
> >> > I personally would find it interesting if someone with a
> >> > higher-end system (e.g. 2 physical CPUs, with 6 or 8 cores per
> >> > CPU) was to do the same test (changing -jX to -j{numofcores} of
> >> > course).
> >> >
> >> > --
> >> > | Jeremy
> >> > Chadwick ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??jdc at
> >> > parodius.com | | Parodius
> >> > Networking ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> >> > http://www.parodius.com/ | | UNIX Systems
> >> > Administrator ?? ?? ?? ?? ?? ?? ?? ?? ?? Mountain View, CA, US |
> >> > | Making life hard for others since 1977. ?? ?? ?? ?? ?? ?? ??
> >> > PGP 4BD6C0CB |
> >> >
> >> >
> >> > sched_ule
> >> > ===
> >> > - time make -j2 buildworld
> >> > ??1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io
> >> > 4565pf+0w
> >> > - time make -j2 buildkernel
> >> > ??640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w
> >> >
> >> >
> >> > sched_4bsd
> >> >
> >> > - time make -j2 buildworld
> >> > ??1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io
> >> > 6451pf+0w
> >> > - time make -j2 buildkernel
> >> > ??638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w
> >> >
> >> >
> >> > software
> >> > ==
> >> > * sched_ule test: ??FreeBSD 8.2-STABLE, Thu Dec ??1 04:37:29 PST
> >> > 2011
> >> > * sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST
> >> > 2011
> >>
> >> Hi Jeremy,
> >> thanks for the time you spent on this.
> >>
> >> However, I wanted to ask/let you note 3 things:
> >> 1) Did you use 2 different code base for the test? (one updated on
> >> December 1 and another one on December 12)
> >
> > No; src-all (/usr/src on this system) was not updated between
> > December 1st and December 12th PST. I do believe I updated it
> > today (15th PST). I can/will obviously hold off so that we have a
> > consistent code base for comparing numbers between schedulers
> > during buildworld and/or buildkernel.
> >
> >> 2) Please note that you should have repeated this test several
> >> times (basically until you don't get a standard deviation which is
> >> acceptable with ministat) and report the ministat output
> >
> > This is the first time I have heard of ministat(1). I'm pretty
> > sure I see what it's for and how it applies to this situation, but
> > boy that man page could use some clarification (I have 3 people
> > looking at this thing right now trying to figure out what means
> > what in the graph :-) ). Anyway, graph or not, I see the point.
> >
> > Regarding multiple tests: yup, you're absolutely right, the only
> > way to do it would be to run a sequence of tests repeatedly
> > (probably 10 per scheduler). Reboots and rm -fr /usr/obj/* would
> > be required after each test too, to guarantee empty kernel caches
> > (of all types) consistently every time.
> >
> > What I posted was supposed to give people just a "general idea" if
> > there was any gigantic difference between the two, and there really
> > isn't. But, as others have stated (and you below), buildworld may
> > not be an effective way to "benchmark" what we're trying to test.
> >
> > Hence me wondering exactly what would make for a goo
Re: SCHED_ULE should not be the default
On 12/15/2011 11:56 AM, Attilio Rao wrote: > So, as very first thing, can you try the following: > - Same codebase, etc. etc. > - Make the test 4 times, discard the first and ministat for the other 3 > - Reboot > - Change the steal_thresh value > - Make the test 4 times, discard the first and ministat for the other 3 > > Then report discarded values and the ministated one and we will have > more informations I guess > (also, I don't think devfs contention should play a role here, thus > nevermind about it for now). Results and data at http://www.tancsa.com/ule-bsd.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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 Thu, Dec 15, 2011 at 10:46 AM, Chris Rees wrote: > On 15 December 2011 17:58, O. Hartmann wrote: >> Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it >> is legitimate to compare ZFS and ext4. It would be much more competetive >> to compare Linux BTRFS and FreeBSD ZFS. >> > > > Er... does ext4 guarantee data integrity? > > You're not comparing like with like; please do some research on the > point of ZFS before asserting that they're fair comparisons. > > A fair(er) comparison could be ext4 with UFS+soft-updates. Wouldn't UFS+SUJ be the closest atch? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
2011/12/15 Mike Tancsa : > On 12/15/2011 11:56 AM, Attilio Rao wrote: >> So, as very first thing, can you try the following: >> - Same codebase, etc. etc. >> - Make the test 4 times, discard the first and ministat for the other 3 >> - Reboot >> - Change the steal_thresh value >> - Make the test 4 times, discard the first and ministat for the other 3 >> >> Then report discarded values and the ministated one and we will have >> more informations I guess >> (also, I don't think devfs contention should play a role here, thus >> nevermind about it for now). > > > Results and data at > > http://www.tancsa.com/ule-bsd.html I'm not totally sure, what does burnP6 do? is it a CPU-bound workload? Also, how many threads are spanked in your case for parallel bzip2? Also, it would be very good if you could arrange these tests against newer -CURRENT (with userland and kerneland debugging off). Thanks a lot of your hard work, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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"
Idea for change to boot0
These two changes allow you to set PXE as the default MBR boot selection, which
enables you to write a 'reboot to the network' script. We've found it to be
very useful. What do people think?
Thanks,
Andrew
> Index: usr.sbin/boot0cfg/boot0cfg.c
> ===
> --- usr.sbin/boot0cfg/boot0cfg.c (revision 228359)
> +++ usr.sbin/boot0cfg/boot0cfg.c (working copy)
> @@ -169,7 +169,7 @@
> o_flag = 1;
> break;
> case 's':
> -s_arg = argtoi(optarg, 1, 5, 's');
> +s_arg = argtoi(optarg, 1, 6, 's');
> break;
> case 't':
> t_arg = argtoi(optarg, 1, 0x, 't');
> @@ -472,6 +472,8 @@
> printf("default_selection=F%d (", mbr[OFF_OPT] + 1);
> if (mbr[OFF_OPT] < 4)
> printf("Slice %d", mbr[OFF_OPT] + 1);
> +else if (mbr[OFF_OPT] == 5)
> +print("PXE");
> else
> printf("Drive 1");
> printf(")\n");
> Index: sys/boot/i386/boot0/boot0.S
> ===
> --- sys/boot/i386/boot0/boot0.S (revision 228359)
> +++ sys/boot/i386/boot0/boot0.S (working copy)
> @@ -413,6 +413,7 @@
> 3:
> #endif /* ONLY_F_KEYS */
> #endif /* SIO */
> +check_selection:
> cmpb $0x5,%al # F1..F6 or 1..6 ?
> #ifdef PXE /* enable PXE/INT18 using F6 */
> jne 1f;
> @@ -421,7 +422,6 @@
> #endif /* PXE */
> jae beep# Not in F1..F5, beep
>
> -check_selection:
> /*
>* We have a selection. If it's a bad selection go back to complain.
>* The bits in MNUOPT were set when the options were printed.
--
Andrew Boyerabo...@averesystems.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 15 Dec 2011 21:25, "Kevin Oberman" wrote: > > On Thu, Dec 15, 2011 at 10:46 AM, Chris Rees wrote: > > On 15 December 2011 17:58, O. Hartmann wrote: > >> Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it > >> is legitimate to compare ZFS and ext4. It would be much more competetive > >> to compare Linux BTRFS and FreeBSD ZFS. > >> > > > > > > Er... does ext4 guarantee data integrity? > > > > You're not comparing like with like; please do some research on the > > point of ZFS before asserting that they're fair comparisons. > > > > A fair(er) comparison could be ext4 with UFS+soft-updates. > > Wouldn't UFS+SUJ be the closest atch? Yup. Thanks. Chris ___ 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: Idea for change to boot0
Hi,
This is interesting. I wrote some newer documentation for PXE booting
here:
http://www.freebsd.org/doc/handbook/network-pxe-nfs.html
In 32.8.4, bullet item 1, I mentioned that it is necessary to
configure network booting in the BIOS menu.
With your change, is entering the BIOS menu to configure network booting
still necessary?
--
Craig Rodrigues
rodr...@juniper.net
On Thu, Dec 15, 2011 at 1:21 PM, Andrew Boyer wrote:
> These two changes allow you to set PXE as the default MBR boot selection,
> which enables you to write a 'reboot to the network' script. We've found it
> to be very useful. What do people think?
>
> Thanks,
> Andrew
>
>> Index: usr.sbin/boot0cfg/boot0cfg.c
>> ===
>> --- usr.sbin/boot0cfg/boot0cfg.c (revision 228359)
>> +++ usr.sbin/boot0cfg/boot0cfg.c (working copy)
>> @@ -169,7 +169,7 @@
>> o_flag = 1;
>> break;
>> case 's':
>> - s_arg = argtoi(optarg, 1, 5, 's');
>> + s_arg = argtoi(optarg, 1, 6, 's');
>> break;
>> case 't':
>> t_arg = argtoi(optarg, 1, 0x, 't');
>> @@ -472,6 +472,8 @@
>> printf("default_selection=F%d (", mbr[OFF_OPT] + 1);
>> if (mbr[OFF_OPT] < 4)
>> printf("Slice %d", mbr[OFF_OPT] + 1);
>> + else if (mbr[OFF_OPT] == 5)
>> + print("PXE");
>> else
>> printf("Drive 1");
>> printf(")\n");
>> Index: sys/boot/i386/boot0/boot0.S
>> ===
>> --- sys/boot/i386/boot0/boot0.S (revision 228359)
>> +++ sys/boot/i386/boot0/boot0.S (working copy)
>> @@ -413,6 +413,7 @@
>> 3:
>> #endif /* ONLY_F_KEYS */
>> #endif /* SIO */
>> +check_selection:
>> cmpb $0x5,%al # F1..F6 or 1..6 ?
>> #ifdef PXE /* enable PXE/INT18 using F6 */
>> jne 1f;
>> @@ -421,7 +422,6 @@
>> #endif /* PXE */
>> jae beep # Not in F1..F5, beep
>>
>> -check_selection:
>> /*
>> * We have a selection. If it's a bad selection go back to complain.
>> * The bits in MNUOPT were set when the options were printed.
>
> --
> Andrew Boyer abo...@averesystems.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"
--
Craig Rodrigues
rodr...@crodrigues.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dogfooding over in clusteradm land
On 14 Dec, Poul-Henning Kamp wrote:
> In message <1323868832.5283.9.ca...@hitfishpass-lx.corp.yahoo.com>, Sean
> Bruno
> writes:
>
>>We're seeing what looks like a syncher/ufs resource starvation on 9.0 on
>>the cvs2svn ports conversion box. I'm not sure what resource is tapped
>>out.
>
> Search mailarcive for "lemming-syncer"
That should only produce a slowdown every 30 seconds but not cause a
deadlock.
I'd be more suspicious of a memory allocation deadlock. This can happen
if the system runs short of free memory because there are a large number
of dirty buffers, but it needs to allocate some memory to flush the
buffers to disk.
This could be more likely to happen if you are using a software raid
layer, but I suspect that the recent change to the default UFS block
size from 16K to 32K is the culprit. In another thread bde pointed out
that the BKVASIZE definition in sys/param.h hadn't been updated to match
the new default UFS block size.
* BKVASIZE - Nominal buffer space per buffer, in bytes. BKVASIZE is the
* minimum KVM memory reservation the kernel is willing to make.
* Filesystems can of course request smaller chunks. Actual
* backing memory uses a chunk size of a page (PAGE_SIZE).
*
* If you make BKVASIZE too small you risk seriously fragmenting
* the buffer KVM map which may slow things down a bit. If you
* make it too big the kernel will not be able to optimally use
* the KVM memory reserved for the buffer cache and will wind
* up with too-few buffers.
*
* The default is 16384, roughly 2x the block size used by a
* normal UFS filesystem.
*/
#define MAXBSIZE65536 /* must be power of 2 */
#define BKVASIZE16384 /* must be power of 2 */
The problem is that BKVASIZE is used in a number of the tuning
calculations in vfs_bio.c:
/*
* The nominal buffer size (and minimum KVA allocation) is BKVASIZE.
* For the first 64MB of ram nominally allocate sufficient buffers to
* cover 1/4 of our ram. Beyond the first 64MB allocate additional
* buffers to cover 1/10 of our ram over 64MB. When auto-sizing
* the buffer cache we limit the eventual kva reservation to
* maxbcache bytes.
*
* factor represents the 1/4 x ram conversion.
*/
if (nbuf == 0) {
int factor = 4 * BKVASIZE / 1024;
nbuf = 50;
if (physmem_est > 4096)
nbuf += min((physmem_est - 4096) / factor,
65536 / factor);
if (physmem_est > 65536)
nbuf += (physmem_est - 65536) * 2 / (factor * 5);
if (maxbcache && nbuf > maxbcache / BKVASIZE)
nbuf = maxbcache / BKVASIZE;
tuned_nbuf = 1;
} else
tuned_nbuf = 0;
/* XXX Avoid unsigned long overflows later on with maxbufspace. */
maxbuf = (LONG_MAX / 3) / BKVASIZE;
/*
* maxbufspace is the absolute maximum amount of buffer space we are
* allowed to reserve in KVM and in real terms. The absolute maximum
* is nominally used by buf_daemon. hibufspace is the nominal maximum
* used by most other processes. The differential is required to
* ensure that buf_daemon is able to run when other processes might
* be blocked waiting for buffer space.
*
* maxbufspace is based on BKVASIZE. Allocating buffers larger then
* this may result in KVM fragmentation which is not handled optimally
* by the system.
*/
maxbufspace = (long)nbuf * BKVASIZE;
hibufspace = lmax(3 * maxbufspace / 4, maxbufspace - MAXBSIZE * 10);
lobufspace = hibufspace - MAXBSIZE;
If you are using the new 32K default filesystem block size, then you may
be consuming twice as much memory for buffers than the tuning
calculations think you are using. Increasing maxvnodes is probably the
wrong way to go, since it will increase memory pressure.
As a quick and dirty test, try cutting kern.nbuf in half. The correct
fix is probably to rebuild the kernel with BKVASIZE doubled.
___
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: Idea for change to boot0
On Dec 15, 2011, at 6:40 PM, Craig Rodrigues wrote:
> Hi,
>
> This is interesting. I wrote some newer documentation for PXE booting
> here:
> http://www.freebsd.org/doc/handbook/network-pxe-nfs.html
>
> In 32.8.4, bullet item 1, I mentioned that it is necessary to
> configure network booting in the BIOS menu.
>
> With your change, is entering the BIOS menu to configure network booting
> still necessary?
>
> --
> Craig Rodrigues
> rodr...@juniper.net
>
Nope. You can just do:
# boot0cfg -s 6
# reboot
It saves you from waiting around until the BIOS screen comes up, hitting the
wrong button, etc. etc. On systems with a lot of memory the BIOS start times
are getting ridiculous.
-Andrew
> On Thu, Dec 15, 2011 at 1:21 PM, Andrew Boyer wrote:
>> These two changes allow you to set PXE as the default MBR boot selection,
>> which enables you to write a 'reboot to the network' script. We've found it
>> to be very useful. What do people think?
>>
>> Thanks,
>> Andrew
>>
>>> Index: usr.sbin/boot0cfg/boot0cfg.c
>>> ===
>>> --- usr.sbin/boot0cfg/boot0cfg.c (revision 228359)
>>> +++ usr.sbin/boot0cfg/boot0cfg.c (working copy)
>>> @@ -169,7 +169,7 @@
>>> o_flag = 1;
>>> break;
>>> case 's':
>>> -s_arg = argtoi(optarg, 1, 5, 's');
>>> +s_arg = argtoi(optarg, 1, 6, 's');
>>> break;
>>> case 't':
>>> t_arg = argtoi(optarg, 1, 0x, 't');
>>> @@ -472,6 +472,8 @@
>>> printf("default_selection=F%d (", mbr[OFF_OPT] + 1);
>>> if (mbr[OFF_OPT] < 4)
>>> printf("Slice %d", mbr[OFF_OPT] + 1);
>>> +else if (mbr[OFF_OPT] == 5)
>>> +print("PXE");
>>> else
>>> printf("Drive 1");
>>> printf(")\n");
>>> Index: sys/boot/i386/boot0/boot0.S
>>> ===
>>> --- sys/boot/i386/boot0/boot0.S (revision 228359)
>>> +++ sys/boot/i386/boot0/boot0.S (working copy)
>>> @@ -413,6 +413,7 @@
>>> 3:
>>> #endif /* ONLY_F_KEYS */
>>> #endif /* SIO */
>>> +check_selection:
>>> cmpb $0x5,%al # F1..F6 or 1..6 ?
>>> #ifdef PXE /* enable PXE/INT18 using F6 */
>>> jne 1f;
>>> @@ -421,7 +422,6 @@
>>> #endif /* PXE */
>>> jae beep# Not in F1..F5, beep
>>>
>>> -check_selection:
>>> /*
>>>* We have a selection. If it's a bad selection go back to complain.
>>>* The bits in MNUOPT were set when the options were printed.
>>
>> --
>> Andrew Boyerabo...@averesystems.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"
>
>
>
> --
> Craig Rodrigues
> rodr...@crodrigues.org
--
Andrew Boyerabo...@averesystems.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: dogfooding over in clusteradm land
On 12/14/2011 05:20, Sean Bruno wrote: > We're seeing what looks like a syncher/ufs resource starvation on 9.0 on > the cvs2svn ports conversion box. ... sounds like a good reason not to migrate the history to me. :) -- [^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
Hi, On Thu, Dec 15, 2011 at 2:32 AM, O. Hartmann wrote: > Just saw this shot benchmark on Phoronix dot com today: > > http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzA > it might be worth highlighting that despite Oracle Linux 6.1 Server is using a kernel + compiler almost 2 years old, it still manages to out-perform the bleeding edge FreeBSD :-) Now, from what I've read so far in this thread, it seems that a lot of people are still in abnegation... my 0.2c, - Arnaud > It may be worth to discuss the sad performance of FBSD in some parts of > the benchmark. A difference of a factor 10 or 100 is simply far beyond > disapointing, it is more than inacceptable and by just reading those > benchmarks, I'd like to drop thinking of using FreeBSD even as a backend > server in scientific and business environments. In detail, some of the > SciMark benches look disappointing. The overall image can't help over > the fact that in C-Ray FreeBSD is better performing. > > From the compiler, I'd like say there couldn't be a drop of more than 10 > - 15% in performance - but not 10 or 100 times. > > I'm just thinking about the discussion of SCHED_ULE and all the saur > spots we discussed when I stumbled over the test. > > Regards, > Oliver > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/16/2011 02:41, Arnaud Lacombe wrote: Hi, On Thu, Dec 15, 2011 at 2:32 AM, O. Hartmann wrote: Just saw this shot benchmark on Phoronix dot com today: http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzA it might be worth highlighting that despite Oracle Linux 6.1 Server is using a kernel + compiler almost 2 years old, it still manages to out-perform the bleeding edge FreeBSD :-) Now, from what I've read so far in this thread, it seems that a lot of people are still in abnegation... my 0.2c, - Arnaud This smells like flamebait ... Because everyone with a little love or knowledge about benchmarking would realize that the benchmark is all wrong, and not only that ... they say that the benchmark tests defaults and ZFS, afaik is far from being a default. ___ 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
Arnaud Lacombe wrote: Hi, On Thu, Dec 15, 2011 at 2:32 AM, O. Hartmann wrote: Just saw this shot benchmark on Phoronix dot com today: http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzA it might be worth highlighting that despite Oracle Linux 6.1 Server is using a kernel + compiler almost 2 years old, it still manages to out-perform the bleeding edge FreeBSD :-) serenity# gcc --version gcc (GCC) 4.2.1 20070831 patched [FreeBSD] serenity# uname -r 9.0-RC3 Now, from what I've read so far in this thread, it seems that a lot of people are still in abnegation... my 0.2c, - Arnaud It may be worth to discuss the sad performance of FBSD in some parts of the benchmark. A difference of a factor 10 or 100 is simply far beyond disapointing, it is more than inacceptable and by just reading those benchmarks, I'd like to drop thinking of using FreeBSD even as a backend server in scientific and business environments. In detail, some of the SciMark benches look disappointing. The overall image can't help over the fact that in C-Ray FreeBSD is better performing. From the compiler, I'd like say there couldn't be a drop of more than 10 - 15% in performance - but not 10 or 100 times. I'm just thinking about the discussion of SCHED_ULE and all the saur spots we discussed when I stumbled over the test. Regards, Oliver ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 12/16/11 07:44, Joe Holden wrote: > Arnaud Lacombe wrote: >> Hi, >> >> On Thu, Dec 15, 2011 at 2:32 AM, O. Hartmann >> wrote: >>> Just saw this shot benchmark on Phoronix dot com today: >>> >>> http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzA >>> >> it might be worth highlighting that despite Oracle Linux 6.1 Server is >> using a kernel + compiler almost 2 years old, it still manages to >> out-perform the bleeding edge FreeBSD :-) >> > serenity# gcc --version > gcc (GCC) 4.2.1 20070831 patched [FreeBSD] > > serenity# uname -r > 9.0-RC3 > For the underlying OS, as far as I know, the compiler hasn't as much impact as on userland software since autovectorization and other neat things are not used during system build. From my experience using gcc 4.2 or 4.4/4.5 does not have an impact beyond 3% when SSE isn't explicetly enforced. More interesting is the performance gain due to the architecture. I think it would be very easy for M. Larabel to repeat this benchmark with a "bleeding edge" Ubuntu or Suse as well. And since FreeBSD 9.0 can be compiled with CLANG, it should be possible to compare both also with "bleeding edge" compilers, say FreeBSD 9/CLANG, Ubuntu 12/gcc 4.6.2. >> Now, from what I've read so far in this thread, it seems that a lot of >> people are still in abnegation... >> >> my 0.2c, >> - Arnaud >> >>> It may be worth to discuss the sad performance of FBSD in some parts of >>> the benchmark. A difference of a factor 10 or 100 is simply far beyond >>> disapointing, it is more than inacceptable and by just reading those >>> benchmarks, I'd like to drop thinking of using FreeBSD even as a backend >>> server in scientific and business environments. In detail, some of the >>> SciMark benches look disappointing. The overall image can't help over >>> the fact that in C-Ray FreeBSD is better performing. >>> >>> From the compiler, I'd like say there couldn't be a drop of more than 10 >>> - 15% in performance - but not 10 or 100 times. >>> >>> I'm just thinking about the discussion of SCHED_ULE and all the saur >>> spots we discussed when I stumbled over the test. >>> >>> Regards, >>> Oliver signature.asc Description: OpenPGP digital signature
