Re: soft updates performance
:OK, I'm sold on the general idea of using soft updates; but what :sort of performance improvements should I expect to see? : :I do a kernel compile on a freshly-rebooted box with an without :softupdates; without, it took 20m45s and with soft updates it :still took 20m10s --- this is less than 3% faster, which is :close to statistically insignificant. Is this expected, or is :there some other factor I should look at? : :Greg A kernel compile, like a buildworld, is more a cpu-intensive operation then a disk-intensive operation, so I wouldn't expect a big improvement. Softupdates wins big on anything that does a lot of directory manipulation. For example, extracting a tar archive, rm -rf, news systems, mail systems (to a lesser degree since they fsync() a lot anyway), and general workloads. There is no real downside, so there really isn't any reason to *not* use softupdates. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
* Greg Black <[EMAIL PROTECTED]> [010210 23:33] wrote: > Matt Dillon wrote: > > > Unless you are doing a read-only mount, there are still going to be > > cases where having softupdates turned on can be advantageous. For > > example, installworld will go a lot faster. I also consider softupdates > > a whole lot safer, even if all you are doing is editing an occassional > > file. > > OK, I'm sold on the general idea of using soft updates; but what > sort of performance improvements should I expect to see? > > I do a kernel compile on a freshly-rebooted box with an without > softupdates; without, it took 20m45s and with soft updates it > still took 20m10s --- this is less than 3% faster, which is > close to statistically insignificant. Is this expected, or is > there some other factor I should look at? > Does 'mount' actually show softupdates as active? If not you need to run 'tunefs' on the partition to set them active. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
i've been doing some experiments with vinum, and doing a make buildworld (with obj on the same vinum) without soft-updates~ 1 hour with soft-updates ~ 40 minutes which is a bit better than 3% :-) what i can't figure out is why -j 4 didn't make any difference. btw, this is on 4.2 stable and a PIII dual 900mHz cpu, 500MGB danny In message <[EMAIL PROTECTED]>you write: }:OK, I'm sold on the general idea of using soft updates; but what }:sort of performance improvements should I expect to see? }: }:I do a kernel compile on a freshly-rebooted box with an without }:softupdates; without, it took 20m45s and with soft updates it }:still took 20m10s --- this is less than 3% faster, which is }:close to statistically insignificant. Is this expected, or is }:there some other factor I should look at? }: }:Greg } }A kernel compile, like a buildworld, is more a cpu-intensive operation }then a disk-intensive operation, so I wouldn't expect a big improvement. } }Softupdates wins big on anything that does a lot of directory manipulation. }For example, extracting a tar archive, rm -rf, news systems, }mail systems (to a lesser degree since they fsync() a lot anyway), }and general workloads. } }There is no real downside, so there really isn't any reason to *not* }use softupdates. } } -Matt } } } }To Unsubscribe: send mail to [EMAIL PROTECTED] }with "unsubscribe freebsd-hackers" in the body of the message } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Alfred Perlstein wrote: > * Greg Black <[EMAIL PROTECTED]> [010210 23:33] wrote: > > Matt Dillon wrote: > > > > > Unless you are doing a read-only mount, there are still going to be > > > cases where having softupdates turned on can be advantageous. For > > > example, installworld will go a lot faster. I also consider softupdates > > > a whole lot safer, even if all you are doing is editing an occassional > > > file. > > > > OK, I'm sold on the general idea of using soft updates; but what > > sort of performance improvements should I expect to see? > > > > I do a kernel compile on a freshly-rebooted box with an without > > softupdates; without, it took 20m45s and with soft updates it > > still took 20m10s --- this is less than 3% faster, which is > > close to statistically insignificant. Is this expected, or is > > there some other factor I should look at? > > Does 'mount' actually show softupdates as active? If not you > need to run 'tunefs' on the partition to set them active. Yes, I ran tunefs as per the manual and I checked with mount. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Greg Black wrote: > > Alfred Perlstein wrote: > > > * Greg Black <[EMAIL PROTECTED]> [010210 23:33] wrote: > > > Matt Dillon wrote: > > > > > > > Unless you are doing a read-only mount, there are still going to be > > > > cases where having softupdates turned on can be advantageous. For > > > > example, installworld will go a lot faster. I also consider softupdates > > > > a whole lot safer, even if all you are doing is editing an occassional > > > > file. > > > > > > OK, I'm sold on the general idea of using soft updates; but what > > > sort of performance improvements should I expect to see? > > > > > > I do a kernel compile on a freshly-rebooted box with an without > > > softupdates; without, it took 20m45s and with soft updates it > > > still took 20m10s --- this is less than 3% faster, which is > > > close to statistically insignificant. Is this expected, or is > > > there some other factor I should look at? > > > > Does 'mount' actually show softupdates as active? If not you > > need to run 'tunefs' on the partition to set them active. > > Yes, I ran tunefs as per the manual and I checked with mount. Times for cvsup and system builds changed quite a bit if you let the I/O be handled by the controllers. buildworld obj on 2nd controller 1516.863u 442.821s 57:17.18 57.0% 1246+1450k 49613+196329io 1866pf+0w build with log on 3rd controller 1522.877u 455.119s 56:52.29 57.9% 1238+1446k 45803+196359io 1721pf+0w make world with files on 3 controllers and -j4 1547.296u 553.318s 58:16.61 60.0% 1196+1415k 45943+314666io 1655pf+0w make world with files on 3 controllers and -j4 with softupdates 1539.114u 521.486s 45:54.82 74.7% 1209+1431k 48857+129907io 1858pf+0w Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Danny Braniss <[EMAIL PROTECTED]> writes: > i've been doing some experiments with vinum, and doing a make buildworld > (with obj on the same vinum) > without soft-updates~ 1 hour > with soft-updates ~ 40 minutes > which is a bit better than 3% :-) > > what i can't figure out is why -j 4 didn't make any difference. Because your I/O system is already saturated. The point with -jNN is that one job can run while another is waiting for I/O to complete and vice versa, but as your CPU gets faster the time spent actually compiling etc. becomes insignificant next to the time spent doing I/O, and if you're already doing I/O as fast as you can there's no room for improvement. On a machine with a slower CPU or a faster I/O system, you'd see improvement. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
On Monday, 12 February 2001 at 15:29:17 +0100, Dag-Erling Smorgrav wrote: > Danny Braniss <[EMAIL PROTECTED]> writes: >> i've been doing some experiments with vinum, and doing a make buildworld >> (with obj on the same vinum) >> without soft-updates~ 1 hour >> with soft-updates ~ 40 minutes >> which is a bit better than 3% :-) >> >> what i can't figure out is why -j 4 didn't make any difference. > > Because your I/O system is already saturated. The point with -jNN is > that one job can run while another is waiting for I/O to complete and > vice versa, but as your CPU gets faster the time spent actually > compiling etc. becomes insignificant next to the time spent doing I/O, > and if you're already doing I/O as fast as you can there's no room for > improvement. On a machine with a slower CPU or a faster I/O system, > you'd see improvement. In fact, it's exactly the opposite. 'make world' is CPU-bound, so the speed of the I/O system is irrelevant. If it were I/O bound, soft updates *would* make a difference, because a number of unnecessary writes would be eliminated. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Greg Lehey <[EMAIL PROTECTED]> writes: > In fact, it's exactly the opposite. 'make world' is CPU-bound, so the > speed of the I/O system is irrelevant. If it were I/O bound, soft > updates *would* make a difference, because a number of unnecessary > writes would be eliminated. Read what he writes. Soft updates *did* make a difference - they shaved ~30% off his worldstone. It's parallelization that doesn't make a difference in his case, because his CPU and FSB are fast enough that the I/O system is left completely in the dust. This is a 900 MHz box, probably with a 100 MHz or 133 MHz FSB, not the old 486DX33 you have lying in a corner. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
* Greg Lehey <[EMAIL PROTECTED]> [010212 15:23] wrote: > On Monday, 12 February 2001 at 15:29:17 +0100, Dag-Erling Smorgrav wrote: > > Danny Braniss <[EMAIL PROTECTED]> writes: > >> i've been doing some experiments with vinum, and doing a make buildworld > >> (with obj on the same vinum) > >>without soft-updates~ 1 hour > >>with soft-updates ~ 40 minutes > >> which is a bit better than 3% :-) > >> > >> what i can't figure out is why -j 4 didn't make any difference. > > > > Because your I/O system is already saturated. The point with -jNN is > > that one job can run while another is waiting for I/O to complete and > > vice versa, but as your CPU gets faster the time spent actually > > compiling etc. becomes insignificant next to the time spent doing I/O, > > and if you're already doing I/O as fast as you can there's no room for > > improvement. On a machine with a slower CPU or a faster I/O system, > > you'd see improvement. > > In fact, it's exactly the opposite. 'make world' is CPU-bound, so the > speed of the I/O system is irrelevant. If it were I/O bound, soft > updates *would* make a difference, because a number of unnecessary > writes would be eliminated. Actually compiles are pretty meta-data intensive, almost compiled program is composed of several .o files, without softupdates those .o files are expensive to create. Another thing is temp files for preprocessor output and assembler output, these can be reduced by using -pipe but without -pipe, each compile takes probably 3 file creations, 3 sync ops without softupdates. So basically, using softupdates along with -jN make actually does make a difference. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
:> In fact, it's exactly the opposite. 'make world' is CPU-bound, so the :> speed of the I/O system is irrelevant. If it were I/O bound, soft :> updates *would* make a difference, because a number of unnecessary :> writes would be eliminated. : :Read what he writes. Soft updates *did* make a difference - they :shaved ~30% off his worldstone. It's parallelization that doesn't make :a difference in his case, because his CPU and FSB are fast enough that :the I/O system is left completely in the dust. This is a 900 MHz box, :probably with a 100 MHz or 133 MHz FSB, not the old 486DX33 you have :lying in a corner. : :DES :-- :Dag-Erling Smorgrav - [EMAIL PROTECTED] A suspect a good chunk of that is not using -pipe. I would be interested in buildworld numbers with -pipe vs with -pipe + softupdates. Without -pipe softupdates will make a huge difference due to temporary file creation & deletion. When Kirk first tested softupdates against buildworld, he explicitly tested it with and without -pipe and found that much of the performance benefit (for buildworld) occured when not using -pipe. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
> In fact, it's exactly the opposite. 'make world' is CPU-bound, so the > speed of the I/O system is irrelevant. If it were I/O bound, soft > updates *would* make a difference, because a number of unnecessary > writes would be eliminated. Actually, I have measured that after a certain point make world *is* I/O bound and you can't really get any faster unless you do something to the I/O subsystem. We have several quad Xeons here, and back when I was more interested in measuring this sort of thing I found that I could get a "worldstone" time of around 37 minutes with -j8 and all 4 processors churning away. This was also during the exclusively BGL days of -current and things may scale slightly better or worse now, I dunno, but what I did find was that I could drop this all to something more like 23 minutes simply by putting /usr/src and /usr/obj into MFS (the machine I used also has a gigabyte of memory so this isn't difficult to do). That implies to me, at least, that after a certain point the CPU is going to be the bottleneck. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Matt Dillon wrote: > > :> In fact, it's exactly the opposite. 'make world' is CPU-bound, so the > :> speed of the I/O system is irrelevant. If it were I/O bound, soft > :> updates *would* make a difference, because a number of unnecessary > :> writes would be eliminated. > : > :Read what he writes. Soft updates *did* make a difference - they > :shaved ~30% off his worldstone. It's parallelization that doesn't make > :a difference in his case, because his CPU and FSB are fast enough that > :the I/O system is left completely in the dust. This is a 900 MHz box, > :probably with a 100 MHz or 133 MHz FSB, not the old 486DX33 you have > :lying in a corner. > : > :DES > :-- > :Dag-Erling Smorgrav - [EMAIL PROTECTED] > > A suspect a good chunk of that is not using -pipe. I would be > interested in buildworld numbers with -pipe vs with -pipe + softupdates. > Without -pipe softupdates will make a huge difference due to temporary > file creation & deletion. > > When Kirk first tested softupdates against buildworld, he explicitly > tested it with and without -pipe and found that much of the performance > benefit (for buildworld) occured when not using -pipe. The times I reported earlier are all with -pipe and are on an AMD Thunderbird 900, with 256 MB of PC-133 memory, and using 3 - ATA-66 HD's on different controllers. The elapsed time dropped from 58:16 to 45:54 by using softupdates. Kent > > -Matt > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Jordan Hubbard <[EMAIL PROTECTED]> writes: > [...] That implies to me, at least, that after a certain > point the CPU is going to be the bottleneck. More likely RAM bandwidth. Those 133 Mhz FSBs ought to help, though. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
> Jordan Hubbard <[EMAIL PROTECTED]> writes: > > [...] That implies to me, at least, that after a certain > > point the CPU is going to be the bottleneck. > > More likely RAM bandwidth. Those 133 Mhz FSBs ought to help, though. If RAM bandwidth was the bottleneck here then putting /usr/src and /usr/obj into an MFS would have represented a pessimization over simply leaving that on disk. I would have thought that would be obvious. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Jordan Hubbard <[EMAIL PROTECTED]> writes: > > More likely RAM bandwidth. Those 133 Mhz FSBs ought to help, though. > If RAM bandwidth was the bottleneck here then putting /usr/src and > /usr/obj into an MFS would have represented a pessimization over > simply leaving that on disk. Don't be so sure. Stuff on disk has to be read into memory, and this is generally done by DMAing it off the disk, which locks the memroy bus, then copying it out into userland. With an MFS you skip the first part, unless MFS is stupider than I thought. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
:Thunderbird 900, with 256 MB of PC-133 memory, and using 3 - ATA-66 :HD's on different controllers. The elapsed time dropped from 58:16 to :45:54 by using softupdates. : :Kent That sounds about right for -pipe. The original email was 1 hour vs 40 minutes, a 20 minute difference which seemed a bit high (what I would expect without -pipe). 46 minutes verses 58 minutes is only a 12 minute 20 second difference, which is more inline with what I would expect. Most of the savings is occuring during the dependancy and cleaning step(s). The system creates and deletes a huge number of files in a huge number of directories and softupdates really helps there. Softupdates is not helping much during the actual compilation, which is a cpu-bound step if you use -pipe (the creation of the object files costs nothing because there is no other disk activity going on). The buildworld hits various choke points -- even with -j 128, if there are only 30 files in a library you will generally only see 30 compiles going at once. The final library link stage chokes it down to one process and this will become a pure bandwidth issue for your disk subsystem for a second or so (for the larger libraries). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Matt Dillon wrote: > > :Thunderbird 900, with 256 MB of PC-133 memory, and using 3 - ATA-66 > :HD's on different controllers. The elapsed time dropped from 58:16 to > :45:54 by using softupdates. > : > :Kent > > That sounds about right for -pipe. The original email was > 1 hour vs 40 minutes, a 20 minute difference which seemed a bit > high (what I would expect without -pipe). 46 minutes verses 58 minutes > is only a 12 minute 20 second difference, which is more inline with what > I would expect. > > Most of the savings is occuring during the dependancy and > cleaning step(s). The system creates and deletes a huge > number of files in a huge number of directories and softupdates > really helps there. > > Softupdates is not helping much during the actual compilation, > which is a cpu-bound step if you use -pipe (the creation of the > object files costs nothing because there is no other disk activity > going on). On of the differences between the Thunderbird and the P-III is the FSB. AMD claims it gets 200 out of a 100MHz bus. The P-III are mostly using a 133 MHz FSB. I have a dual mb arriving shortly with a pair of 866's. The next test. I have a cluster project that would be very similar to a buildworld. It will end up using 2 - P-II 400's, the AMD, and the P-III's. Some people I work with run batch jobs that run overnight but I think they could wait for them to run with a small version of Purdue's ACME. A few hours of their time would pay for a small cluster. They don't have any problem with work. It is turning jobs around that seems to be the bottle neck. > > The buildworld hits various choke points -- even with -j 128, if > there are only 30 files in a library you will generally only see > 30 compiles going at once. The final library link stage chokes > it down to one process and this will become a pure bandwidth issue > for your disk subsystem for a second or so (for the larger libraries). I have gotten used to watching my buildworld's with top on occasions. I have setiathome running with a "nice" value for nice. On the AMD system, when the buildworld is hitting an I/O bottleneck, seti will be using 40% or more of the system. When it is compute bound, seti doesn't get any time. I think the accrual of time by seti is a sort of integrated past history of the system availability due to an I/O type of bottle neck during the buildworld. It follows the % value reported by time fairly well. Softupdates is the first time the time % value on the AMD went above 60%. I think this indicates I have an overall I/O bottle neck. The current version of seti writes a small blip of data to the HD about every 30-60 seconds and so there isn't much HD interaction going on there. I'm thinking about adding 2 - Ultra-160 scsi's to the system at some point. For the kind of stuff I do, iozone seems to cover the HD activity the best. The tagged queing of the scsi deals with small record random I/O much better than the IDE drives do. From what I have read, FreeBSD supports tagged queing on the new IBM IDE drives but I don't have any of them to use to test. One other point that I would like to understand is why -j4 takes longer on all of my systems. That goes against what everyone claims should happen. Kent > > -Matt -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Kent Stewart <[EMAIL PROTECTED]> writes: > One other point that I would like to understand is why -j4 takes > longer on all of my systems. That goes against what everyone claims > should happen. More concurrent jobs means more contention and more overhead. Increasing the number of jobs boosts performance to a certain point; past this point, performance starts decreasing again. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
> One other point that I would like to understand is why -j4 takes > longer on all of my systems. That goes against what everyone claims > should happen. With how many running processors? If you're running -j4 on a uniprocessor system, you're only introducing competition for already scarce CPU resources, though -j2 can be a speedup since this allows one target build to run while another is in an I/O wait. I've only seen a speedup with -j4 when using at least 2 CPUs. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Jordan Hubbard wrote: > > > One other point that I would like to understand is why -j4 takes > > longer on all of my systems. That goes against what everyone claims > > should happen. > > With how many running processors? If you're running -j4 on a > uniprocessor system, you're only introducing competition for already > scarce CPU resources, though -j2 can be a speedup since this allows > one target build to run while another is in an I/O wait. I've only > seen a speedup with -j4 when using at least 2 CPUs. It was a uniprocessor system. The folklore has it doing more but all I ever saw it produce was more competition, which resulted in a longer running buildworld. Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
> It was a uniprocessor system. The folklore has it doing more but all I You've been listening to the wrong folklore then, that's all. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Jordan Hubbard wrote: > > > It was a uniprocessor system. The folklore has it doing more but all I > > You've been listening to the wrong folklore then, that's all. :) True but that is what section 19.4.6.5 in the Handbook implies. It also reads for -current but it has said that since 3.x was the latest stable. I would add -j4 and my buildworld would slow down a few percent. Kent > > - Jordan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Matthew Emmerton wrote: > > On Mon, 12 Feb 2001, Jordan Hubbard wrote: > > > > One other point that I would like to understand is why -j4 takes > > > longer on all of my systems. That goes against what everyone claims > > > should happen. > > > > With how many running processors? If you're running -j4 on a > > uniprocessor system, you're only introducing competition for already > > scarce CPU resources, though -j2 can be a speedup since this allows > > one target build to run while another is in an I/O wait. I've only > > seen a speedup with -j4 when using at least 2 CPUs. > > FWIW, I've got an ancient dual-CPU machine (Pentium 133s) with an onboard > Adaptec 7870 hooked to a pair of SCSI-2 drives. > > With any intensive build activity (make buildworld, or a kernel > recompile), -j8 gives me the best results. (I came to this conclusion > after profiling a kernel build using -j2/4/6/8/10/12.) > > The only explanation I can give in my case is that the onboard 7870 is a > PCI device and is the main bottleneck in the system (my motherboard is a > very interesting EISA/PCI combo, mfgd in 1991). > > Although Jordan's quite right in saying that using anything larger than > -j2 on a uniprocessor machine will usually be futile, in the world of SMP > things are much stranger, so it's good to experiment. (-j8 is > about a 50% speedup over -j2). YMMV. > > -- > Matt Emmerton -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
Sorry about the other one. I intended to start over. I did but not the way I wanted :(. Matthew Emmerton wrote: > > On Mon, 12 Feb 2001, Jordan Hubbard wrote: > > > > One other point that I would like to understand is why -j4 takes > > > longer on all of my systems. That goes against what everyone claims > > > should happen. > > > > With how many running processors? If you're running -j4 on a > > uniprocessor system, you're only introducing competition for already > > scarce CPU resources, though -j2 can be a speedup since this allows > > one target build to run while another is in an I/O wait. I've only > > seen a speedup with -j4 when using at least 2 CPUs. > > FWIW, I've got an ancient dual-CPU machine (Pentium 133s) with an onboard > Adaptec 7870 hooked to a pair of SCSI-2 drives. > > With any intensive build activity (make buildworld, or a kernel > recompile), -j8 gives me the best results. (I came to this conclusion > after profiling a kernel build using -j2/4/6/8/10/12.) > > The only explanation I can give in my case is that the onboard 7870 is a > PCI device and is the main bottleneck in the system (my motherboard is a > very interesting EISA/PCI combo, mfgd in 1991). > > Although Jordan's quite right in saying that using anything larger than > -j2 on a uniprocessor machine will usually be futile, in the world of SMP > things are much stranger, so it's good to experiment. (-j8 is > about a 50% speedup over -j2). YMMV. You have me interested now. I should have a dual P-III 866 running in a few days and I will find out. It is intended to end up running 2 or more Ultra-160 scsi HD's. That will come after I get some timing done with ATA-100 IDE HD's on separate controllers. I haven't tried running -j2 and as soon as my base case with no "-jn" specified and softupdate finishes, I will try "-j2". Kent > > -- > Matt Emmerton -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
On Mon, 12 Feb 2001, Jordan Hubbard wrote: > > One other point that I would like to understand is why -j4 takes > > longer on all of my systems. That goes against what everyone claims > > should happen. > > With how many running processors? If you're running -j4 on a > uniprocessor system, you're only introducing competition for already > scarce CPU resources, though -j2 can be a speedup since this allows > one target build to run while another is in an I/O wait. I've only > seen a speedup with -j4 when using at least 2 CPUs. FWIW, I've got an ancient dual-CPU machine (Pentium 133s) with an onboard Adaptec 7870 hooked to a pair of SCSI-2 drives. With any intensive build activity (make buildworld, or a kernel recompile), -j8 gives me the best results. (I came to this conclusion after profiling a kernel build using -j2/4/6/8/10/12.) The only explanation I can give in my case is that the onboard 7870 is a PCI device and is the main bottleneck in the system (my motherboard is a very interesting EISA/PCI combo, mfgd in 1991). Although Jordan's quite right in saying that using anything larger than -j2 on a uniprocessor machine will usually be futile, in the world of SMP things are much stranger, so it's good to experiment. (-j8 is about a 50% speedup over -j2). YMMV. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
On Mon, Feb 12, 2001 at 10:36:40PM -0800, Jordan Hubbard wrote: > > With how many running processors? If you're running -j4 on a > uniprocessor system, you're only introducing competition for already > scarce CPU resources, though -j2 can be a speedup since this allows > one target build to run while another is in an I/O wait. I've only > seen a speedup with -j4 when using at least 2 CPUs. Interesting. When I asked about optimal values on this list maybe a year ago, I was told that -j(4 * NCPU) was a good choice. I guess that doesn't work for NCPU == 1. -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
void wrote: > > On Mon, Feb 12, 2001 at 10:36:40PM -0800, Jordan Hubbard wrote: > > > > With how many running processors? If you're running -j4 on a > > uniprocessor system, you're only introducing competition for already > > scarce CPU resources, though -j2 can be a speedup since this allows > > one target build to run while another is in an I/O wait. I've only > > seen a speedup with -j4 when using at least 2 CPUs. > > Interesting. When I asked about optimal values on this list maybe a > year ago, I was told that -j(4 * NCPU) was a good choice. I guess that > doesn't work for NCPU == 1. I did some testing last night and found that there was a difference of 50% between -j4 and not running softupdates and running softupdates and no -j4. The buildworld elapsed clock times were 58 minutes for the first case and 38 minutes for the last case. Even -j2 added 11 minutes to the elapsed build time. I thought I had been hit by one of the file system cron jobs on -j2 and ran it again. The difference was around 10 seconds between the two runs. The user time isn't that much different but the -jn contention really slows the buildworld down. The times are in a table at http://dsl1-160.dynacom.net/freebsd/urban_legends.html kent > > -- > Ben > > "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." >--Kate C. (no, different Ben, I would have stayed up) -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
In message <[EMAIL PROTECTED]> void writes: : On Mon, Feb 12, 2001 at 10:36:40PM -0800, Jordan Hubbard wrote: : > : > With how many running processors? If you're running -j4 on a : > uniprocessor system, you're only introducing competition for already : > scarce CPU resources, though -j2 can be a speedup since this allows : > one target build to run while another is in an I/O wait. I've only : > seen a speedup with -j4 when using at least 2 CPUs. : : Interesting. When I asked about optimal values on this list maybe a : year ago, I was told that -j(4 * NCPU) was a good choice. I guess that : doesn't work for NCPU == 1. Back at Solbourne (Sparc multiprossors running in the 50-75MHz range), the optimal value was determined imperically to be between 1.3 and 1.7 times the number of CPUs rounded up. A 8 CPU system made the kernel fasted at about -j13 or so. But the whole range from -j 10 to -j 15 gave within 5% of the optimal value. I've seen speedups on systems with very fast memory subsystems, but only decent disks with -j 4. My PII 500 was one such beast. However, -j 4 wasn't 2x faster than -j 2. It was more like 1.2 or 1.3 x faster (eg 20% or so). If a -j 1 kernel build took 600s, a -j 2 build would take 375-400s while a -j 4 would take more like 320-340. I also had a lot of memory on this box, so the extra jobs weren't fighting each other for that. NFS was involved, so maybe that throws the mix off :-) Your milage may vary. This sort of thing is fairly dependent on the actual system, but it varies from no gain to big gains. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
