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
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
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
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
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 softupdates?
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, Matt.
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
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
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(), and
: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
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
: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
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
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 timecounter.
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 want
to
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 440FX dual P6 systems,
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 a
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
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 file
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
: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
::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 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
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
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),
the
:
: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),
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.278s
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.278s
: 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
: 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 ---
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.278s
33 matches
Mail list logo
