Hello!
On Sat, 13 May 2006, Matthew D. Fuller wrote:
On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of
Kris Kennaway, and lo! it spake thus:
FYI, INVARIANTS adds checks but does not (is not supposed to) divert
code paths.
It does at least in UMA; it does a lot of
Hello!
On Sat, 13 May 2006, Jonathan Noack wrote:
Have you tried putting I586_CPU in there? See
http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020696.html.
Thanks for suggestion. I've just tried it, performance difference is
indistinguishable.
Also, use the link0 option
Matthew D. Fuller wrote:
On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of
Kris Kennaway, and lo! it spake thus:
FYI, INVARIANTS adds checks but does not (is not supposed to) divert
code paths.
It does at least in UMA; it does a lot of bzero()/NULL'ing out of
memory, which
Hello!
On Fri, 12 May 2006, Kris Kennaway wrote:
%Sys %Intr %Idl
RELENG_6 + rl0 45 40 15
RELENG_6 + fxp0 45 35 20
%Sys %Intr %Idl time md5 -t wall clock time
RELENG_6 + rl0 34 24 42 1:43
RELENG_6 + fxp0
Hello!
On Fri, 12 May 2006, Kris Kennaway wrote:
So maybe it's time to add, say,
options INVARIANTS_EXTENDED
for these new and expensive checks, and leave only basic and cheap (yet
effective for bug hunting) asserts enabled when only
options INVARIANTS
is defined?
No, they are
On 05/13/06 01:59, Dmitry Pryanishnikov wrote:
On Fri, 12 May 2006, Kris Kennaway wrote:
%Sys %Intr %Idl
RELENG_6 + rl0 45 40 15
RELENG_6 + fxp0 45 35 20
%Sys %Intr %Idl time md5 -t wall clock time
RELENG_6 + rl0 34
On Sat, May 13, 2006 at 03:01:18AM -0400 I heard the voice of
Jonathan Noack, and lo! it spake thus:
Have you tried putting I586_CPU in there? See
http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020696.html.
As Peter Jeremy mentioned in
On Sat, May 13, 2006 at 08:59:01AM +0300, Dmitry Pryanishnikov wrote:
I'm just trying to understand why performance of RELENG_6 is worse than
in RELENG_4 _that much_, and whether this sad situation can be improved
somehow.
The architecture of the system substantially changed in the 5.X
On Sat, May 13, 2006 at 10:37:40AM -0400 I heard the voice of
Kris Kennaway, and lo! it spake thus:
With respect to INVARIANTS, you just need to get used to the fact
that running thousands of checks for bugs is incompatible with
running at optimal speed.
(I'm not sure what the point of
On Sat, May 13, 2006 at 10:52:32AM -0500, Matthew D. Fuller wrote:
On Sat, May 13, 2006 at 10:37:40AM -0400 I heard the voice of
Kris Kennaway, and lo! it spake thus:
With respect to INVARIANTS, you just need to get used to the fact
that running thousands of checks for bugs is
On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of
Kris Kennaway, and lo! it spake thus:
FYI, INVARIANTS adds checks but does not (is not supposed to) divert
code paths.
It does at least in UMA; it does a lot of bzero()/NULL'ing out of
memory, which might hide later
Hello!
On Fri, 28 Apr 2006, Kris Kennaway wrote:
makeoptions CONF_CFLAGS=-fno-builtin
I don't know, it needs to be tested in your particular case.
I've built another kernel, adding back
makeoptions CONF_CFLAGS=-fno-builtin
options QUOTA
Results are almost the same as w/o these
Hello!
On Tue, 2 May 2006, Robert Watson wrote:
options INVARIANTS
options INVARIANT_SUPPORT
In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly
expanded to test a much larger set of invariants, and also incorporate kernel
use-after-free checking,
On Fri, May 12, 2006 at 11:32:44PM +0300, Dmitry Pryanishnikov wrote:
Hello!
On Tue, 2 May 2006, Robert Watson wrote:
options INVARIANTS
options INVARIANT_SUPPORT
In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been
significantly expanded to test a much larger set of
On Fri, May 12, 2006 at 11:25:58PM +0300, Dmitry Pryanishnikov wrote:
Hello!
On Fri, 28 Apr 2006, Kris Kennaway wrote:
makeoptions CONF_CFLAGS=-fno-builtin
I don't know, it needs to be tested in your particular case.
I've built another kernel, adding back
makeoptions
On Thu, 27 Apr 2006, Dmitry Pryanishnikov wrote:
options INVARIANTS
options INVARIANT_SUPPORT
In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly
expanded to test a much larger set of invariants, and also incorporate kernel
use-after-free checking,
On 28/04/06, Kris Kennaway [EMAIL PROTECTED] wrote:
On Fri, Apr 28, 2006 at 03:31:17PM +0300, Dmitry Pryanishnikov wrote:
Hello!
On Thu, 27 Apr 2006, Kris Kennaway wrote:
Thanks for your suggestions, they've made a difference (though not as big
as one could hope).
On Thu, Apr 27, 2006
On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote:
Does 'makeoptions DEBUG=-g' add any kind of performance hit or
overhead as I noticed it wasnt default in 5.4 but is in 6.0.
No. It just means that a debug kernel is built in addition to the
normal kernel. The major benefit is that if you do
Peter Jeremy wrote:
On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote:
Does 'makeoptions DEBUG=-g' add any kind of performance hit or
overhead as I noticed it wasnt default in 5.4 but is in 6.0.
No. It just means that a debug kernel is built in addition to the
normal kernel. The major
Dominic Marks wrote:
Peter Jeremy wrote:
On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote:
Does 'makeoptions DEBUG=-g' add any kind of performance hit or
overhead as I noticed it wasnt default in 5.4 but is in 6.0.
No. It just means that a debug kernel is built in addition to the
normal
On Sun, Apr 30, 2006 at 10:05:40AM +0100, Chris wrote:
On 28/04/06, Kris Kennaway [EMAIL PROTECTED] wrote:
On Fri, Apr 28, 2006 at 03:31:17PM +0300, Dmitry Pryanishnikov wrote:
Hello!
On Thu, 27 Apr 2006, Kris Kennaway wrote:
Thanks for your suggestions, they've made a difference
Hello!
On Thu, 27 Apr 2006, Kris Kennaway wrote:
Thanks for your suggestions, they've made a difference (though not as big
as one could hope).
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
makeoptions CONF_CFLAGS=-fno-builtin
Non-default option; this may
On Fri, Apr 28, 2006 at 03:31:17PM +0300, Dmitry Pryanishnikov wrote:
Hello!
On Thu, 27 Apr 2006, Kris Kennaway wrote:
Thanks for your suggestions, they've made a difference (though not as big
as one could hope).
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
Hello!
I've done simple (yet, I hope, reality-reflecting) performance benchmarking
different STABLE branches (4 vs 5 vs 6) using the following hardware:
CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x665 Stepping = 5
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
makeoptions CONF_CFLAGS=-fno-builtin
Non-default option; this may conceivably affect performance.
options INVARIANTS
options INVARIANT_SUPPORT
These definitely effect performance, much more in 5.x and 6.x
Kris Kennaway a écrit :
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
options QUOTA
This definitely effects performance on 6.x since it makes your
filesystem giant-locked, which may also interfere with your network
processing.
Why would QUOTA affect
On Thu, Apr 27, 2006 at 08:26:06PM +0200, [EMAIL PROTECTED] wrote:
Kris Kennaway a ?crit :
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
options QUOTA
This definitely effects performance on 6.x since it makes your
filesystem giant-locked, which may also
Kris Kennaway a écrit :
On Thu, Apr 27, 2006 at 08:26:06PM +0200, [EMAIL PROTECTED] wrote:
Kris Kennaway a ?crit :
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
options QUOTA
This definitely effects performance on 6.x since it makes your
filesystem
You wrote that Giant is needed in 6.0 and now you write it has been
removed.
In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not
normally required, making file system operations faster. When you enable
QUOTA, you basically get back to the 4.x behavior where Giant is needed
Bartosz Fabianowski wrote:
You wrote that Giant is needed in 6.0 and now you write it has been
removed.
In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not
normally required, making file system operations faster. When you
enable QUOTA, you basically get back to the 4.x
On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote:
Bartosz Fabianowski wrote:
You wrote that Giant is needed in 6.0 and now you write it has been
removed.
In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not
normally required, making file system operations
Kris Kennaway wrote:
On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote:
Why isn't QUOTA mpsafe then?
Because code doesn't grow on trees. There are uncommitted patches
though - perhaps you can test them and get back to the author with
your feedback.
What? There is a
On Thu, Apr 27, 2006 at 04:43:07PM -0400, Mike Jakubik wrote:
Kris Kennaway wrote:
On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote:
Why isn't QUOTA mpsafe then?
Because code doesn't grow on trees. There are uncommitted patches
though - perhaps you can test them and
On Apr 27, 2006, at 11:12, Kris Kennaway wrote:
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
options QUOTA
This definitely effects performance on 6.x since it makes your
filesystem giant-locked, which may also interfere with your network
processing.
Any
On Thu, Apr 27, 2006 at 01:57:02PM -0700, Doug Hardie wrote:
On Apr 27, 2006, at 11:12, Kris Kennaway wrote:
On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:
options QUOTA
This definitely effects performance on 6.x since it makes your
filesystem giant-locked,
35 matches
Mail list logo
