| View previous topic :: View next topic |
| Author |
Message |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6214
Location: Dallas area
|
 Posted: Thu Mar 24, 2011 1:36 pm Post subject: |
 |
|
Woohoo... from Con's blog
| Quote: | | and BFS for 2.6.38 can be grabbed here: |
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
 |
bollucks
l33t
Joined: 27 Oct 2004
Posts: 606
|
| Posted: Thu Mar 24, 2011 9:45 pm Post subject: |
|
|
Jobs == number of CPUs is the fastest way to finish a build. The overloaded idea goes way back to when scheduling was bad. Increasing the number these days just overloads other resources in your machine like the I/O subsystem and the Virtual Memory subsystem.
See: http://ck.kolivas.org/patches/bfs/reverse-scalability.png which refers to a quad core machine.
So when using BFS you don't need to overload your system. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Thu Mar 24, 2011 11:17 pm Post subject: |
|
|
| Yamakuzure wrote: | | Gusar wrote: | | High -j is not "unusually high load", it's a ridiculous artificial scenario. |
No and no. Sorry, but on a quad-core cpu the recommended value is -j9 |
Err, the recommendation was always cores+1. So -j9 would be the recommendation if you have a hyperthreaded quad-core. And with BFS, the recommendation is without the +1.
| Yamakuzure wrote: | with which my laptop became completely unusable before the "cgroups-console-hack" was invented whenever I emerged packages with --jobs in the EMERGE_DEFAULT_OPTS. With the console-hack (now superseded by 2.6.38 with auto scheduler) I can keep on working like there was no load. In the meantime portage did a world update, vmware is running with windows xp (needed for a cisco vpn tunnel to a customer), several openoffice documents are open, kmail, knode, amarok is playing music and typing this text goes without problem. Load of my system: 18.5 to 25.0 -- unthinkable before those cgroups methods came up.
And this is not a "ridiculous artificial scenario", it is something I have twice a week. You know, I _do_ want to get the updates finished as soon as possible without having to go for a walk for hours because I can't use my machine... |
Hmm, I wonder... How fast would the process be with a reasonable -j setting? Just as fast, I'd say. And how usable the machine would be while doing it?
This all still looks to me like "if I overload my machine with a high -j, it's not responsive, and this cgroup thing helps." Well, don't overload your machine and you won't need miracle patches.
| Anon-E-moose wrote: | Woohoo... from Con's blog | Quote: | | and BFS for 2.6.38 can be grabbed here: |
|
That was fast. His previous message read as if it'll take at least a week or two. |
|
| Back to top |
|
|
pilla
Bodhisattva
Joined: 07 Aug 2002
Posts: 7731
Location: Underworld
|
| Posted: Fri Mar 25, 2011 3:26 am Post subject: |
|
|
hyperthread != 2 cores. In some cases, performance can be even worse with hyperthreads enabled. Or at least that was the case when they started shipping pentium 4 HT chips.
_________________
"I'm just very selective about the reality I choose to accept." -- Calvin |
|
| Back to top |
|
|
wswartzendruber
Veteran
Joined: 23 Mar 2004
Posts: 1261
Location: Idaho, USA
|
| Posted: Fri Mar 25, 2011 5:45 am Post subject: |
|
|
This might be the answer to my issues of VirtualBox completely stalling whenever both cores are busy.
I'm still waiting for hardened-sources-2.6.38. |
|
| Back to top |
|
|
peter4
Guru
Joined: 19 Jul 2005
Posts: 359
Location: Wroclaw, Poland
|
| Posted: Fri Mar 25, 2011 8:24 am Post subject: |
|
|
I don't get it at all. Can someone give me a real life example when this patch would make a positive impact on desktop responsiveness? Before you ask, make -j16 is not a real life example.  |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2305
Location: Adendorf, Germany
|
| Posted: Fri Mar 25, 2011 8:52 am Post subject: |
|
|
| Gusar wrote: | | Yamakuzure wrote: | | Gusar wrote: | | High -j is not "unusually high load", it's a ridiculous artificial scenario. |
No and no. Sorry, but on a quad-core cpu the recommended value is -j9 |
Err, the recommendation was always cores+1. So -j9 would be the recommendation if you have a hyperthreaded quad-core. And with BFS, the recommendation is without the +1. |
Depends where you look.
x86-handbook: Nr of CPUs + 1
amd64-handbook: No recommendation
distcc-handbook: "(A common strategy is setting N as twice the number of total CPUs + 1 available) | Gusar wrote: | Hmm, I wonder... How fast would the process be with a reasonable -j setting? Just as fast, I'd say. And how usable the machine would be while doing it?
This all still looks to me like "if I overload my machine with a high -j, it's not responsive, and this cgroup thing helps." Well, don't overload your machine and you won't need miracle patches. |
I do not know whethere you followed the "Unresponsiveness" thread in the amd64-board, but even -j5 (your recommendation) and a load below 4.0 made the machine unusable prior those patches. And as I want to be able to use parallel merges (yes, the speed gain is enormous!) it will go beyond 4.0 for sure. | Gusar wrote: | | Anon-E-moose wrote: | Woohoo... from Con's blog | Quote: | | and BFS for 2.6.38 can be grabbed here: |
|
That was fast. His previous message read as if it'll take at least a week or two. |
*sigh* This "BFS-Advertising" is unnerving. Look, the problem with responsiveness on heavy load (not necessarily "overload") is a common problem. Keeping on telling people they had to patch kernel sources from an external source by hand solves nothing. If BFS was this good, when will it make into the main tree then? (*) (answer: never.) | pilla wrote: | | hyperthread != 2 cores. In some cases, performance can be even worse with hyperthreads enabled. Or at least that was the case when they started shipping pentium 4 HT chips. |
Hyperthreading on Pentium4/Xeon-netburst and Hyperthreading on Pentium Core-i are not really the same. I tried the kernel with nothing, SCHED_SMT, SCHED_MC and both. And the latter was performing best.
(*): don't understand me wrong: I really like the idea of the BFS scheduler. And the main reason for not going into the mainline is, that it does not scale beyond 12-16 logical CPUs (A 16-CPU-machine would suffer from BFS) which is against the mainline policy of having to upscale to 4096 CPUs. But if it did wonders, there would be a solution. Until then it is just an optional hack-by-hand for people who know what they are doing and want to handle the consequence.
| peter4 wrote: | | I don't get it at all. Can someone give me a real life example when this patch would make a positive impact on desktop responsiveness? Before you ask, make -j16 is not a real life example. |
I did already. But here it is again:
On my laptop a vmware workstation runs with Windows XP. At the same time I am doing a wolrd update. I have several documents open with openoffice. Kontact sits on another screen for e-mail, calendar, news feeds and Usenet. Amarok is playing music in the background and I am typing this text.
for more details why this was an unthinkable scenario (even without the world update) prior the first cgroup-hack can be read up here:
https://forums.gentoo.org/viewtopic-t-793263.html
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Fri Mar 25, 2011 9:28 am Post subject: |
|
|
| Yamakuzure wrote: | | But if it did wonders, there would be a solution. Until then it is just an optional hack-by-hand for people who know what they are doing and want to handle the consequence. |
You're talking nonsense. The solution, as in pf-sources is to substitute a scheduler designed for 4096 CPUs, for a scheduler designed for 1-16-ish CPUs, which is what people actually have in desktops/laptops. Different scheduler designs.
BFS isn't in the mainline kernel, because of crappy politics 
The "consequence", with a tiny bit of BASH aliasing as I showed above, is a smoother desktop experience than with the mainline kernel.
This is Gentoo, ya know. What's with the adversion to anything "by-hand"? We're supposed to be optimizing by hand  In comparison, the wonder patch is a Ubuntu-type scheduling hack. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Fri Mar 25, 2011 9:42 am Post subject: |
|
|
| pilla wrote: | | hyperthread != 2 cores. In some cases, performance can be even worse with hyperthreads enabled. Or at least that was the case when they started shipping pentium 4 HT chips. |
HT has evolved since then. And I know it's not the same as two real cores. But hey, my netbook can decode 720p thanks to it. And my Core i3 desktop benefits from it too. It's a very nice thing to have.
@Yamakuzure: BFS isn't in the kernel because of personality clashes. No other reason, just that. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Fri Mar 25, 2011 10:01 am Post subject: |
|
|
| PaulBredbury wrote: | | What's with the adversion to anything "by-hand"? We're supposed to be optimizing by hand |
Entropy, my friend, entropy .
| peter4 wrote: | | I don't get it at all. Can someone give me a real life example when this patch would make a positive impact on desktop responsiveness? Before you ask, make -j16 is not a real life example. |
It's simple.
There's one side of debate that runs here about whether it makes sense to push one's machine load using a high value of -j . That discussion has somewhat drifted from the initial topic and has now nothing to do with the patch in itself.
The patch indeed allows a machine to still be responsive under a high load. The proof is that even with this (granted: stupid) example of -j16 or -j64, a machine still is responsive, which was clearly impossible before. It demonstrates the patch clearly brings a huge enhancement on high loads. The example being stupid doesn't demonstrate the patch doesn't work; the patch *does* work and reaches the goal it was targeting.
The (silly) example hence does demonstrate the patch works (I love to paraphrase myself). This means you can trust the patch to bring the announced enhancements.
My point was that since Gentoo involves compiling a lot, which usually implies a higher load for a certain amount of time, the patch comes handy for the duration of the compile process: it allows your machine to still be responsive while compiling. It also comes handy for you can also slightly increase the -j value (above the general rule 2*CPU+1) to truly load your CPU and keep it at 100% most of the time *and* still use your machine without having to wait. That's an example I'd bring to reply to your question. Now it's up to you to find a good use case on how to load your machine appropriately — use whatever makes you happy .
All in all, my point is that the patch really does what had been announced.
Now whether it's useful or not, whether the same level of responsiveness can be achieved some other way, I don't really care. It'll be useful to me and I *will* use it. Period. All the noise that is made aside is none of my concerns  .
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6214
Location: Dallas area
|
| Posted: Fri Mar 25, 2011 1:00 pm Post subject: |
|
|
| Yamakuzure wrote: | | Gusar wrote: | | Anon-E-moose wrote: | Woohoo... from Con's blog | Quote: | | and BFS for 2.6.38 can be grabbed here: |
|
That was fast. His previous message read as if it'll take at least a week or two. |
*sigh* This "BFS-Advertising" is unnerving. Look, the problem with responsiveness on heavy load (not necessarily "overload") is a common problem. Keeping on telling people they had to patch kernel sources from an external source by hand solves nothing. If BFS was this good, when will it make into the main tree then? (*) (answer: never.) |
Others have mentioned why it won't make it to the "main tree", but having used it for quite a while now, I've not seen problems.
Bottom line, don't like BFS, don't use it, simple as that.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
peter4
Guru
Joined: 19 Jul 2005
Posts: 359
Location: Wroclaw, Poland
|
| Posted: Fri Mar 25, 2011 2:26 pm Post subject: |
|
|
| VinzC wrote: | | My point was that since Gentoo involves compiling a lot, which usually implies a higher load for a certain amount of time, the patch comes handy for the duration of the compile process: it allows your machine to still be responsive while compiling. |
I just made an experiment. I started a kernel build with nice make -j2 (which is more of a real life example) and started up a 1080p movie in mplayer. The playback was perfectly smooth.
I can also say, that i never had any problems even with 1080p fullscreen youtube videos during compiling (with -j2).
EDIT: all of it on 2.6.37 without the "wonder patch", forgot to mention that. |
|
| Back to top |
|
|
StalkerNOVA
n00b
Joined: 08 Mar 2011
Posts: 12
|
| Posted: Sat Mar 26, 2011 4:59 am Post subject: |
|
|
| Didn't get it. In pf-sources 2.6.38 r1 not all options can be found for cgroups... |
|
| Back to top |
|
|
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
|
| Posted: Sat Mar 26, 2011 6:02 am Post subject: |
|
|
| VinzC wrote: |
The patch indeed allows a machine to still be responsive under a high load. The proof is that even with this (granted: stupid) example of -j16 or -j64, a machine still is responsive, which was clearly impossible before. It demonstrates the patch clearly brings a huge enhancement on high loads. The example being stupid doesn't demonstrate the patch doesn't work; the patch *does* work and reaches the goal it was targeting. |
I guess the point is, somewhat, that with BFS -j16 is unnecessary/superfluous.
That's what I'm gathering from reading this. Not an expert myself, but I will say shit just plain builds faster with BFS. Some time when you're bored, boot a kernel with BFS, build a package with -j2. Then boot into a regular ol' kernel using what is it, CFS? Do the same build with -j2, and time both.
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Sat Mar 26, 2011 11:05 am Post subject: |
|
|
| cach0rr0 wrote: | I guess the point is, somewhat, that with BFS -j16 is unnecessary/superfluous.
That's what I'm gathering from reading this. Not an expert myself, but I will say shit just plain builds faster with BFS. Some time when you're bored, boot a kernel with BFS, build a package with -j2. Then boot into a regular ol' kernel using what is it, CFS? Do the same build with -j2, and time both. |
Well, it's really not about how long it takes with or without the patch. Just watch /proc/loadavg with and without and observe when your computer starts lagging. Your computer will start lagging later (as the load average is higher) with the patch.
Now I'll probably need to compare this with BFS. I think I never quite took time (nor knew how) to assess the benefits of it.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Mar 26, 2011 12:56 pm Post subject: |
|
|
| using a high -j16 or more is not stupid for a cpu, it's even a need if you use distcc and have others cores/cpu that need to be feed, so stop assuming a high -jX is a stupid value for a cpu. Like all options, it could be stupid with a high value for someone, and stupid with a low value for someone else... |
|
| Back to top |
|
|
albright
Advocate
Joined: 16 Nov 2003
Posts: 2588
Location: Near Toronto
|
| Posted: Sat Mar 26, 2011 2:02 pm Post subject: |
|
|
For what it is worth, with 2.6.38 (with or without BFS),
my rsync hourly backup (snapback2 based) quite often
make kde apps unresponsive for several seconds.
My rsync is ioniced and niced but to no avail.
I *think* that 2.6.38 is somewhat better than earlier kernels
(the app freeze is of shorter duration when it happens and
I *think* it happens less frequently).
Just my 2 cents.
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme) |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Sun Mar 27, 2011 3:56 am Post subject: |
|
|
| albright wrote: | | My rsync is ioniced and niced but to no avail. |
There's more to it than that. Look at e.g. commit=.
Also, make sure that you are using CFQ (Q for I/O Queuing, rather than S for Scheduler) rather than BFQ in the kernel, because IIRC, BFQ doesn't support ionice.
| Code: | $ zgrep CFQ /proc/config.gz
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y |
|
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2305
Location: Adendorf, Germany
|
| Posted: Mon Mar 28, 2011 10:56 am Post subject: |
|
|
@PaulBredbury :
@Gusar :
@Anon-E-moose :
Could you all please _read_ a post completely before answering like that? Thanks. Here is what I mean: | Anon-E-moose wrote: | | Bottom line, don't like BFS, don't use it, simple as that. |
While I wrote: | Yamakuzure wrote: | | Don't understand me wrong: I really like the idea of the BFS scheduler. |
And about politics: | BFS FAQs wrote: | How scalable is it?
I don't own the sort of hardware that is likely to suffer from using it, so I can't find the upper limit. Based on first principles about the overhead of locking, and the way lookups occur, I'd guess that a machine with 16 CPUS or more would start to have exponentially less performance (thanks Ingo for confirming this).
Are you looking at getting this into mainline?
No. They would be crazy to use this scheduler anyway since it won't scale to their 4096 cpu machines. The only way is to rewrite it to work that way, or to have more than one scheduler in the kernel. I don't want to do the former, and mainline doesn't want to do the latter.
Can it be made to scale to 4096 CPUs?
Sure I guess you could run one runqueue per CPU package instead of a global one and so on, but I have no intention whatsoever at doing that because it will compromise the performance where *I* care. |
Finally:
Do you think if you set your -j value to the number of CPU(-core)s you really fully use your CPU with all the I/O, even with /var/tmp/portage being in tmpfs, on every single compiler operation? There is a difference between "IOWait/User/System" you can not deny.
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
|
| Posted: Mon Mar 28, 2011 5:48 pm Post subject: |
|
|
| Yamakuzure wrote: | And about politics: | BFS FAQs wrote: | How scalable is it?
I don't own the sort of hardware that is likely to suffer from using it, so I can't find the upper limit. Based on first principles about the overhead of locking, and the way lookups occur, I'd guess that a machine with 16 CPUS or more would start to have exponentially less performance (thanks Ingo for confirming this).
Are you looking at getting this into mainline?
No. They would be crazy to use this scheduler anyway since it won't scale to their 4096 cpu machines. The only way is to rewrite it to work that way, or to have more than one scheduler in the kernel. I don't want to do the former, and mainline doesn't want to do the latter.
Can it be made to scale to 4096 CPUs?
Sure I guess you could run one runqueue per CPU package instead of a global one and so on, but I have no intention whatsoever at doing that because it will compromise the performance where *I* care. |
|
I do hope you are detecting the large, large amount of sarcasm coming from Con there.
If you bold the right parts it becomes more obvious:
| Quote: |
a machine with 16 CPUS or more would start to have exponentially less performance (thanks Ingo for confirming this)
|
(and it's not the first time very talented people with useful patches have been ignored by mainline)
| Quote: |
since it won't scale to their 4096 cpu machines
|
(the joke of course being, "I'm so glad they used their 4096 core machines to test with and confirm the issue, or else all the other people out there with 4096 core machines might suffer!")
| Quote: |
The only way is to rewrite it to work that way, or to have more than one scheduler in the kernel. I don't want to do the former, and mainline doesn't want to do the latter.
|
So, yes, politics. The FAQ is loaded with sarcasm, and subtle daggers at the mainline folks for refusing to have a second scheduler in the kernel. If you didn't see it above, they won't accept BFS unless he rewrites it to scale to 4096 CPU's, which he for good reason has no intention of doing
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
BenderBendingRodriguez
Tux's lil' helper
Joined: 19 Feb 2010
Posts: 101
|
| Posted: Mon Mar 28, 2011 7:43 pm Post subject: |
|
|
| I honestly don't understand where the problem lies, leave CFQ as default but just introduce BFS and in documentation write that it is for desktop PC's. People who have 4096 CPU's compile their own kernels anyway and have enough expertise to know BFS won't scale to their "mediocre" CPU count |
|
| Back to top |
|
|
neocrust
n00b
Joined: 21 Sep 2010
Posts: 9
|
| Posted: Tue Mar 29, 2011 8:37 am Post subject: |
|
|
I think that kernel 2.6.3* with BFS/BFQ is better than kernel 2.6.38 with "~200 lines" patch 
At least for me  |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2305
Location: Adendorf, Germany
|
| Posted: Tue Mar 29, 2011 9:14 am Post subject: |
|
|
Yes, I do believe as well that a kernel with BFS performs better on a desktop/notebook style machine. For such machines BFS is a marvelous scheduler.
@cach0rr0 : Yes, I do understand the FAQ I quoted. I thought they are right clear, and so I did not explain them. ... But thanks for doing so.
But why are you linking an old discussion about PaX versus Exec-Shield that is 8 years old? PaX is great. For a hardened system (like production servers) that value protection higher than user privileges. Something like PaX should nowhere go near the mainline kernel, as it is something no normal desktop user could live with easily. (Or at all...)
BFS is something completely different. We work on servers with 16+ CPUs, so BFS would be a big no-no on those. But for desktops and notebooks I really don't see why it is denied from mainline. I *do* understand the politics behind that squabbling, but that doesn't mean I agree with their attitude.
@Thread:
However, this thread is about the new cgroups auto scheduler, and I did some experiments with it.
The best "balance" of load I can get when using: | Code: | MAKEOPTS="-j15 -l8"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --jobs --load-average=8.0" |
Although the load limitation is a double load (on 4 logical CPUs), I can get htop to show a CPU usage of 90-95% while merging multiple packages. The process trees then show that most processes are in D state.
I guess this settings would be too high for a system with more than one hard drive, or even a RAID, as Disk Wait (or IOWait in general) might be a lot less significant there. For my single hard-drived notebook it seems to work, and the machine stays responsible all the time.
_________________
Edited 220,176 times by Yamakuzure |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia
|
| Posted: Wed Mar 30, 2011 10:44 pm Post subject: |
|
|
| krinn wrote: | | using a high -j16 or more is not stupid for a cpu, it's even a need if you use distcc and have others cores/cpu that need to be feed, so stop assuming a high -jX is a stupid value for a cpu. Like all options, it could be stupid with a high value for someone, and stupid with a low value for someone else... |
Err, with distcc you're not using a CPU, you're using several CPUs. So of course a high -j makes sense there, to feed all of them. What's the connection between distcc and "it's not stupid for a single CPU", how do you go from one to the other?
| Yamakuzure wrote: | However, this thread is about the new cgroups auto scheduler, and I did some experiments with it.
The best "balance" of load I can get when using:
Code:
MAKEOPTS="-j15 -l8"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --jobs --load-average=8.0"
Although the load limitation is a double load (on 4 logical CPUs), I can get htop to show a CPU usage of 90-95% while merging multiple packages. The process trees then show that most processes are in D state.
I guess this settings would be too high for a system with more than one hard drive, or even a RAID, as Disk Wait (or IOWait in general) might be a lot less significant there. For my single hard-drived notebook it seems to work, and the machine stays responsible all the time. |
Did you time how long it takes to finish all tasks with that setup? And did you time how long would the same tasks take with BFS and a -j that's equal to the number of cores? |
|
| Back to top |
|
|
DestroyFX
n00b
Joined: 05 Dec 2005
Posts: 44
|
| Posted: Thu Mar 31, 2011 5:23 pm Post subject: |
|
|
Here from the timed kernel compilation test I made, with my X6 CPU:
time make -j6
real 2m43.303s
user 13m2.339s
sys 2m1.649s
time make -j7
real 2m44.023s
user 13m6.413s
sys 2m1.957s
time make -j8
real 2m44.176s
user 13m10.244s
sys 2m2.877s
time make -j12
real 2m50.535s
user 13m42.303s
sys 2m7.399s
It was with the 2.6.38-rcSomething without BFS with the wonder patch....
The optimal compilation speed was with -jCore. The performance go down with -jCore+1 and more.
I remember that with the 2.6.36-, -jCore+1 was better except with BFS who required -jCore (and was more fast than without BFS with -jCore+1). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
