On Fri, Mar 31, 2000 at 12:24:27PM +0200, a little birdie told me
that Brad Knowles remarked
> At 5:44 PM -0600 2000/3/30, Matthew D. Fuller wrote:
>
> > Does softupdates provide faster performance than async/noatime? I keep
> > /usr/src and /usr/obj as such, would it be faster with softupdate
At 5:44 PM -0600 2000/3/30, Matthew D. Fuller wrote:
> Does softupdates provide faster performance than async/noatime? I keep
> /usr/src and /usr/obj as such, would it be faster with softupdates? And
> if so, why?
Of course, once you ask this question, the next logical one that
fol
In message <[EMAIL PROTECTED]>, Jesper Skriver writes:
>On the box below, a relative new dual PIII box, with a Intel
>motherboard, does it use the i8254 or the PIIX timecounter ?
>
>[...]
>Timecounter "PIIX" frequency 3579545 Hz
You're using the PIIX.
--
Poul-Henning Kamp FreeBSD c
On Thu, 30 Mar 2000, Matthew D. Fuller wrote:
> Does softupdates provide faster performance than async/noatime? I keep
> /usr/src and /usr/obj as such, would it be faster with softupdates? And
> if so, why?
Async is theoretically faster if it is implemented properly. It is poorly
implemented
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>The general problem with the timecounter is that not only is the hardware
>indeterminant, but the timecounter structure itself is *NOT* MP safe,
>at least not by my read of it.
Well, read again then :-)
I've had a paper in the
In message <[EMAIL PROTECTED]> Matthew Dillon writes:
: Async should not be used unless you really like restoring crashed
: filesystems from tape :-). Oh, and perhaps when one is doing an
: initial OS install from CDRom :-). Async itself will not cause a crash,
: but if your mac
:>:At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
:>[...]
:>6 minutes 20 seconds (about 7%).
:
:I'm seeing the same order of improvement still.
:
:--
:Bob Bishop (0118) 977 4017 international code +44 118
:[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK
:In message <[EMAIL PROTECTED]> "Matthew D. Fuller" writes:
:: The question at task is, is buildworld one of them? I don't think that
:: situation comes up a lot in buildworld, but I'm not exactly an authority
:: on it...
:
:About 6 months ago, softupdates made things about 5% faster than async
>:At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
>[...]
>6 minutes 20 seconds (about 7%).
I'm seeing the same order of improvement still.
--
Bob Bishop (0118) 977 4017 international code +44 118
[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK
To
In message <[EMAIL PROTECTED]> "Matthew D. Fuller" writes:
: The question at task is, is buildworld one of them? I don't think that
: situation comes up a lot in buildworld, but I'm not exactly an authority
: on it...
About 6 months ago, softupdates made things about 5% faster than async
for mak
On Thu, Mar 30, 2000 at 04:00:43PM -0800, a little birdie told me
that David O'Brien remarked
> On Thu, Mar 30, 2000 at 05:44:53PM -0600, Matthew D. Fuller wrote:
> > Does softupdates provide faster performance than async/noatime?
>
> In general it depends. Softupdates is faster on creating a fi
On Thu, Mar 30, 2000 at 05:44:53PM -0600, Matthew D. Fuller wrote:
> Does softupdates provide faster performance than async/noatime?
In general it depends. Softupdates is faster on creating a file and then
deleteing it before both hit the disk. Softupdates nulifies out the
creation. Async woul
On Wed, Mar 29, 2000 at 10:04:17PM -0800, a little birdie told me
that Matthew Dillon remarked
>
> Ha! I found it. Kirk gets the credit --- softupdates was turned on
> in one of the machine's /usr/obj's and off on the other machine's.
>
> So softupdates improves buildworld times by
> > > >Only the i8254 timecounter hardware currently needs interrupt-disabling,
> > > >but it is hopefully never used on SMP machines.
> > >
> > > Worse. It is used by default on SMP machines which don't sport the
> > > PIIX timecounter.
> >
> > ie. anything using the PIIX3 or older (think 440F
On Thu, Mar 30, 2000 at 10:05:26AM -0800, Mike Smith wrote:
> > >> Just following on from this, one thing that I can see immediately being
> > >> very important to me at least is a spinlock in the timecounter structure.
> > >> Calcru and various other things call microtime(), and we're going to
> >> Just following on from this, one thing that I can see immediately being
> >> very important to me at least is a spinlock in the timecounter structure.
> >> Calcru and various other things call microtime(), and we're going to want
> >> to lock out updates and parallel accesses to the timeco
In message <[EMAIL PROTECTED]> Matthew Dillon writes:
: The general problem with the timecounter is that not only is the hardware
: indeterminant, but the timecounter structure itself is *NOT* MP safe,
: at least not by my read of it.
:
: It also doesn't appear to be interrupt saf
:In message <[EMAIL PROTECTED]>, Bruce Ev
:ans writes:
:>On Wed, 29 Mar 2000, Mike Smith wrote:
:>
:>> Just following on from this, one thing that I can see immediately being
:>> very important to me at least is a spinlock in the timecounter structure.
:>> Calcru and various other things call m
Oops.. some of us are using i8254 on SMP machines. This motherboard is a
Intel PR440FX.
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #5: Mon Mar 27 20:39:24 ES
:At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
:
:> So softupdates improves buildworld times by a significant margin.
:
: Uh, I think we've known this for a while now. ;-)
:
: Still, I'm looking forward to finding out what the new timings
:are for SMP builds with the new c
In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>On Wed, 29 Mar 2000, Mike Smith wrote:
>
>> Just following on from this, one thing that I can see immediately being
>> very important to me at least is a spinlock in the timecounter structure.
>> Calcru and various other things call microtime
On Wed, 29 Mar 2000, Mike Smith wrote:
> Just following on from this, one thing that I can see immediately being
> very important to me at least is a spinlock in the timecounter structure.
> Calcru and various other things call microtime(), and we're going to want
> to lock out updates and par
At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
> So softupdates improves buildworld times by a significant margin.
Uh, I think we've known this for a while now. ;-)
Still, I'm looking forward to finding out what the new timings
are for SMP builds with the new code (bo
At 9:45 PM -0500 2000/3/29, Chuck Robey wrote:
>> Difference: 19 minutes, or a 21% improvement. Bob Bishop got 7% with an
>> earlier patch (hopefully his system is no longer locking up and he can
>> repeat his test with the current stuff).
>
> Goddamn. That's significant! Congratulations,
Matthew Dillon wrote:
>
> :> time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
> :>
> :> 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615p
f+0w
> :>
> :> time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
> :>
> :> 4696.987u 1502.
:> 4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 10889+4270io 1779pf+0w
:
:Can I ask why is there a huge difference in the number of io (251k vs 4k)?
:What is so different between 4.0 and 5.0 that causes this?
:
:--
:
:Andy Farkas
Ha! I found it. Kirk gets the credit ---
:> time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
:>
:> 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
:>
:> time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
:>
:> 4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 108
On Wed, 29 Mar 2000, Matthew Dillon wrote:
> time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
>
> 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
>
> time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
>
> 4696.987u 1502.2
On Wed, 29 Mar 2000, Matthew Dillon wrote:
> time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
>
> 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
>
> time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
>
> 4696.987u 1502.
> > For the single-process (1-fork) case, syscall overhead improved
> > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
> > improvement in the competing-cpu's case is due to the movement of the
> > MP lock inward somewhat (even for syscalls that aren't MP safe)
:
:You should be able to remove the splhigh() from sigprocmask and run it
:MPSAFE. At least, I can't find a reason not to (and it works here, yes).
:
:\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
:
Tentitively it looks like we will indeed be able to make sigprocmask()
> For the single-process (1-fork) case, syscall overhead improved
> moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
> improvement in the competing-cpu's case is due to the movement of the
> MP lock inward somewhat (even for syscalls that aren't MP safe),
>
time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 10889+4270io 1779pf
33 matches
Mail list logo
