Re: Intel TurboBoost in practice
On Sun, 25 Jul 2010, Alexander Motin wrote: The numbers that you are showing doesn't show much difference. Have you tried buildworld? If you mean relative difference -- as I have told, it's mostly because of my CPU. It's maximal boost is 266MHz (8.3%), but 133MHz of them is enabled most of time if CPU is not overheated. It probably doesn't, as it works on clear table under air conditioner. So maximal effect I can expect on is 4.2%. In such situation 2.8% probably not so bad to illustrate that feature works and there is space for further improvements. If I had Core i5-750S I would expect 33% boost. Can I recommend the use of ministat(1) and sample sizes of at least 8 runs per configuration? Robert If you mean absolute difference, here are results or four buildworld runs: hw.acpi.cpu.cx_lowest=C1: 4654.23 sec hw.acpi.cpu.cx_lowest=C2: 4556.37 sec hw.acpi.cpu.cx_lowest=C2: 4570.85 sec hw.acpi.cpu.cx_lowest=C1: 4679.83 sec Benefit is about 2.1%. Each time results were erased and sources pre-cached into RAM. Storage was SSD, so disk should not be an issue. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
Robert Watson wrote: > On Sun, 25 Jul 2010, Alexander Motin wrote: >>> The numbers that you are showing doesn't show much difference. Have >>> you tried buildworld? >> >> If you mean relative difference -- as I have told, it's mostly because >> of my CPU. It's maximal boost is 266MHz (8.3%), but 133MHz of them is >> enabled most of time if CPU is not overheated. It probably doesn't, as >> it works on clear table under air conditioner. So maximal effect I can >> expect on is 4.2%. In such situation 2.8% probably not so bad to >> illustrate that feature works and there is space for further >> improvements. If I had Core i5-750S I would expect 33% boost. > > Can I recommend the use of ministat(1) and sample sizes of at least 8 > runs per configuration? Thanks for pushing me to do it right. :) Here is 3*15 runs with fresh kernel with disabled debug. Results are quite close to original: -2.73% and -2.19% of time. x C1 + C2 * C3 +-+ |+* x| |+* x| |+* x| |+* x| |+* x| |+* x| |+* x| |+ ** x| |+ + ** xx| |+ + ** ** xx x| | |__M_A| | |A| | ||A| | +-+ NMinMax Median AvgStddev x 15 12.68 12.84 12.69 12.698667 0.039254966 + 15 12.35 12.36 12.35 12.351333 0.0035186578 Difference at 95.0% confidence -0.347333 +/- 0.0208409 -2.7352% +/- 0.164119% (Student's t, pooled s = 0.0278687) * 15 12.41 12.44 12.42 12.42 0.0075592895 Difference at 95.0% confidence -0.278667 +/- 0.0211391 -2.19446% +/- 0.166467% (Student's t, pooled s = 0.0282674) I also checked one more aspect -- TurboBoost works only when CPU runs at highest EIST frequency (P0 state). I've reduced dev.cpu.0.freq from 3201 to 3067 and repeated the test: x C1 + C2 * C3 +-+ | x + *| | x + *| | x + *| | x + * *| | x x+ * *| | x x+ + * *| | x x+ + * *| | x x+ + * *| | x x+ + + + * *| ||MA| | | |_MA_|| |M_A_|| +-+ NMinMax Median AvgStddev x 15 13.72 13.73 13.72 13.72 0.0048795004 + 15 13.79 13.82 13.8 13.80 0.0072374686 Difference at 95.0% confidence 0.08 +/- 0.00461567 0.582949% +/- 0.0336337% (Student's t, pooled s = 0.00617213) * 15 13.89 13.9 13.8913.894 0.0050709255 Difference at 95.0% confidence 0.170667 +/- 0.00372127 1.24362% +/- 0.0271164% (Student's t, pooled s = 0.00497613) In that case using C2 or C3 predictably caused small performance reduce, as after falling to sleep, CPU needs time to wakeup. Even if tested CPU0 won't ever sleep during test, it's TLB shutdown IPIs to other cores still probably could suffer from waiting other cores' wakeup. Obviously in first test these 0.58% and 1.24% were subtracted from the TurboBoost's maximal benefit of 4.3% on this CPU. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pageout question
On Sun, 25 Jul 2010 23:43:08 +0300 Andriy Gapon wrote: > on 25/07/2010 23:28 RW said the following: > > I didn't say it say it was guaranteed. I just think the scenario > > where a first pass ends up between the watermarks is rare. And when > > it happens I don't see a compelling reason to do extra paging to > > reach an arbitrary target. > > Well, it seems neither I nor you have data to show whether it's rare > or not (and it would greatly depend on workload too). > As to "arbitrary target" - well, that's the whole point of > hysteresis-like behavior. We start paging also at an "arbitrary" > point. If after the first pass with light-paging the high watermark isn't reached then the choices are 1) loop and immediately do a heavy-paging pass. 2) wait and let the daemon get woken-up for another light-paging pass - only go to heavy-paging when this strategy isn't keeping up with demand. To me (2) is doing the right thing. It's trying to satisfy demand from existing clean pages, and only paging heavily as a last resort. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pageout question
on 25/07/2010 23:43 Andriy Gapon said the following:
> on 25/07/2010 23:28 RW said the following:
>> I didn't say it say it was guaranteed. I just think the scenario where
>> a first pass ends up between the watermarks is rare. And when it
>> happens I don't see a compelling reason to do extra paging to reach an
>> arbitrary target.
>
> Well, it seems neither I nor you have data to show whether it's rare or not
> (and
> it would greatly depend on workload too).
> As to "arbitrary target" - well, that's the whole point of hysteresis-like
> behavior. We start paging also at an "arbitrary" point.
Well, it seems that you are right (at least to a certain degree) - with
"moderately high" memory load (starting lots of memory hungry "real"
applications and not letting them sit idle) a single pass was always sufficient.
Even with my suggested change! :-) I.e. that single pass was always able to
shoot to or over the high watermark.
So, in fact, there is not much (any?) difference between current code and
patched code in this case.
But not quite so with stress2 swap test.
In that case more than one pass was needed in almost all the cases. Again, this
is with patched vm_pageout().
Which brings another interesting point which was overlooked initially.
vm_pageout() loop can make at most two passes back-to-back, after that it slows
down to make an additional pass every 1/2 seconds:
if (vm_pages_needed) {
/*
* Still not done, take a second pass without waiting
* (unlimited dirty cleaning), otherwise sleep a bit
* and try again.
*/
++pass;
if (pass > 1)
msleep(&vm_pages_needed,
&vm_page_queue_free_mtx, PVM, "psleep",
hz / 2);
} else {
With the patched code and stress2 I indeed observed pagedaemon spending time in
this sleep.
On the other hand, current unpatched code is more optimistic about calling it
done. So even if only a handful of pages is freed and available memory goes
just above low watermark, pagedaemon would decide that it had a successful pass
and would reset pass count to zero. Those freed pages would, of course, get
consumed immediately and a new pass would be requested. Since the history is
lost at this point, there would be no rate limit for the new pass.
So my _theory_ is that in very harsh conditions doing true hysteresis would
result in many _accounted_ passes and thus throttled down pagedaemon. On the
other hand, the current code would still do many passes because of the constant
memory pressure, but they will be (mostly) unaccounted and thus pagedaemon would
be scanning pages 'like crazy'.
In other words: with current code available page count would rapidly oscillate
around low watermark, while with patched code available page count would mostly
stay low.
Not sure which one is better. But for me, in such extreme conditions, slowing
things down sounds better than spinning pagedaemon.
P.S.
Just in case, I would like to point out that the patch doesn't change condition
when the waiters are notified about available memory - it is still
!vm_page_count_min(). The patches only changes when vm_pages_needed is reset.
This is kind of obvious, but I decided to make it explicit.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
freebsd-hackers@freebsd.org
discount news : the South Africa's World Cup has finished ,but i know that the promotions in www.yong-rong.com for the South Africa's World Cup has not finished ,do you know ?i think the Website can be tested,because I have bought some ,that company mainly sell all kinds of MP3,TV,Motorbike,Cellphone,Laptop etc,you can buy their products as soon as possible ,maybe the promotions will be end soon. good luck ,Greeting ! 5--& ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pageout question
on 26/07/2010 20:53 RW said the following: > If after the first pass with light-paging the high watermark isn't > reached then the choices are > > 1) loop and immediately do a heavy-paging pass. > > 2) wait and let the daemon get woken-up for another light-paging pass - > only go to heavy-paging when this strategy isn't keeping up with demand. > > To me (2) is doing the right thing. It's trying to satisfy demand from > existing clean pages, and only paging heavily as a last resort. Well, based on my observations, if the first pass doesn't reach the high watermark, then we are in a high pressure situation and so we would have to do some heavy-lifting anyways. In my opinion, it's better to start doing more work at once than trying to pretend that situation would somehow resolve itself. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: lint(1) improvements from OpenBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/25 02:39, Frederic Culot wrote: > Hi, > > I noticed on the the FreeBSD list of projects and ideas an item related to > lint(1) and the port of improvements from the OpenBSD project: > > http://www.freebsd.org/projects/ideas/ideas.html#p-lint > > I would like to know more about this project but unfortunately no technical > contact was specified on the web page, hence I write to the hackers list. > > Does someone have more information related to this project (what improvements > does the text refer to)? > Has someone started working on it? I think it's talking about OpenBSD's xlint (src/usr.bin/xlint). No I am not aware of anyone working on this. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMTi3/AAoJEATO+BI/yjfBxMAIAK5Hz21ipEJFMao1U0BXUEun WGofq+cokgXYA94JsfOrl/KmwwaEetZVp21Gc1yyL+Kp4ZYvzpv+eEzdm98TH5rv wHJp298j/hs0gxkrDP2XqnIrjd+YCuJg19CbZ7rEC6SeuAJ4mEJR1DW6dpmM7TSa lZnGgTnZp6SMUY2knU2GQfQjd+f0IXP370ksjSF3CPMwaKHzKoCLLWHR9uBacGjb QLPU4AvmExxfTa6icsfCVNNcIeFdq6653Hq9HJdsvGbkX623PMxzcG/BfeIETDUo /zwOnx1Pp27cpvVNf7K6tqt2aNZlr2Fjxq9mz4hy6yAnVmJiqX2vz1Z2jAN6lrw= =YWXj -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
