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
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
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
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'
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 ever
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 ru
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
> 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
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 introduci
> 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 r
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 per
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
: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 se
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 su
> 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 /
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:
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 w
> 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 mak
:> 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 di
* 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)
> >>w
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 writ
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
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
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. F
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 w
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 i
* 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
: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%
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 i
29 matches
Mail list logo
