headers
Terry Vernon | 3 Jan 2006 04:42
Picon

Poor memory performance, amd64 obsd3.8

Tyan Thunder K8S s2448 Mobo

Dual Opteron 848 (2.2ghz 1mb 64b)

Registered ECC DDR 400mhz memory at 2GB (4x512mb)

Dual 36GB 10k rpm scsi (LSI controller)

Dual gigE Broadcom Ethernet ports.

OpenBSD 3.8 amd64 bsd.mp GENERIC kernel (no mods)

I have experienced terrible memory performance results while testing my
system with ubench. My processors perform better on obsd 3.8 than linux
2.4.21smp but the memory performance for random reading, writing, store, and
delete tasks are terrible according to ubench. These numbers are only used
for comparison as there is no chart, but on obsd the performance numbers are
rounded at 69,000 and on the linux kernel it's 329000. ubench can be used
from the current ports tree, it's the one I use.

Are there any caveats or pitfalls I'm running into here or is something else
at play?

Does anyone know of plans to port a newer release of gcc for amd64
architectures? (as I think recompiling the source tree might help a bit but
the current gcc is dated before opterons were supported fully, no
-march=opteron option)

Thanks for any information.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Otto Moerbeek | 3 Jan 2006 10:26

rthreads: plugging mem leaks

Hi,

One of the large missing pieces of the rthreads puzzle is cleaning up
after a thread exits. 

This is all more complicated that you'd think since a thread may be
referenced by pthread_join() or pthread_detach() _after_ it has exited.

Cleaning up stacks is even more nasty: the stack is needed to call
threxit(). Cleaning up the stack cannot be done in the regular cleanup
code, sice the we do not know if the threxit() has actually been
completed.

Anyway, here's a diff to fix all this. It's nice to see the
pthread_specific regress test first eat a lot of memory, and then
giving it back piece by piece.

Thanks to Marco Hyman for providing some valuable hints.

	-Otto

Index: Makefile
===================================================================
RCS file: /cvs/src/lib/librthread/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile	1 Jan 2006 19:32:30 -0000	1.7
+++ Makefile	3 Jan 2006 09:11:59 -0000
 <at>  <at>  -7,7 +7,8  <at>  <at>  CFLAGS+=-Wall -g -Werror -Wshadow
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray Lai | 3 Jan 2006 19:23

Re: -Wall cleanup for vi

Hi,

This diff removes ``operation on `VARIABLE' may be undefined'' -Wall
warnings.  No binary change on i386.  Please look at my previous
diff as well.

-Ray-

Index: ex/ex_txt.c
===================================================================
RCS file: /cvs/src/usr.bin/vi/ex/ex_txt.c,v
retrieving revision 1.8
diff -u -r1.8 ex_txt.c
--- ex/ex_txt.c	17 Oct 2005 19:12:16 -0000	1.8
+++ ex/ex_txt.c	3 Jan 2006 18:12:22 -0000
 <at>  <at>  -400,8 +400,8  <at>  <at> 
 			++scno;

 	/* Get the previous shiftwidth column. */
-	cno = scno;
-	scno -= --scno % sw;
+	cno = scno--;
+	scno -= scno % sw;

 	/*
 	 * Since we don't know what comes before the character(s) being
Index: vi/v_txt.c
===================================================================
RCS file: /cvs/src/usr.bin/vi/vi/v_txt.c,v
retrieving revision 1.16
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ray Lai | 3 Jan 2006 20:02

Re: -Wall cleanup for vi

Hi,

This diff removes a ``comparison is always true due to limited range
of data type'' -Wall warning.  An infinte loop occurs if isspace()
is false for 0x01 to 0xff (and then to 0x00 due to integer overflow).

The relevant code is:
    149 	/* Find a non-printable character to use as a message separator. */
    150 	for (ch = 1; ch <= MAX_CHAR_T; ++ch)
    151 		if (!isprint(ch)) {
    152 			gp->noprint = ch;
    153 			break;
    154 		}
    155 	if (ch != gp->noprint) {
    156 		msgq(sp, M_ERR, "079|No non-printable character found");
    157 		return (1);
    158 	}
    159 	return (0);
(ch and gp->noprint are CHAR_T types, typedefed to unsigned char,
and MAX_CHAR_T is defined to be 0xff.)

Please look at my previous diffs as well.  Thank you.

-Ray-

Index: common/key.c
===================================================================
RCS file: /cvs/src/usr.bin/vi/common/key.c,v
retrieving revision 1.7
diff -u -r1.7 key.c
(Continue reading)

Permalink | Reply | 2 comments |
headers
kp21 | 4 Jan 2006 15:53
Picon

Re: pf modulate state & TCP option SACK modulation by pf - patch (2)

On 30 Dec 2005 at 14:41, K_Pfaff wrote:
> > I have posted recently a message describing the problem with SACK option 
> > values when "pf" was used to modulate state.
> 
On 30 Dec 2005 at 9:22, Mike Frantzen wrote:
> There are a few bugs in the patch ....

Yes, indeed. There was a serious bug in that patch - TCP_SACK option 
length was not checked properly! 
An optimised and shorter (& safer) version of patch provided by Mike 
Franzen was undoubtly better, but (since he had no time to test it) it did 
not write the SACK changes back to mbuf. 

I have corrected and tested the code and  there is my proposal.
It works and changes the SACK values correctly.

The following things were changed:

1. I add additional variable "thoptlen" 
   meaning "tcp header options length"
It is used to store the length of options. It will be used at the end of 
pf_modulate_sack function:
+        if (copyback)
+                m_copyback(m, off + sizeof(*th), thoptlen, opts);
thoptlen is used instead of "olen" since olen variable gets changed and 
cannot be used in here.

It was the important thing to correct to make it work.
Additional changes are only my suggestions:
(Continue reading)

Permalink | Reply | 0 comments |
headers
kp21 | 4 Jan 2006 16:00
Picon

Re: pf modulate state & TCP option SACK modulation by pf - patch (3) corrected

/Sorry, attachment was ripped off

On 30 Dec 2005 at 14:41, K_Pfaff wrote:
> > I have posted recently a message describing the problem with SACK option 
> > values when "pf" was used to modulate state.
> 
On 30 Dec 2005 at 9:22, Mike Frantzen wrote:
> There are a few bugs in the patch ....

Yes, indeed. There was a serious bug in that patch - TCP_SACK option 
length was not checked properly! 
An optimised and shorter (& safer) version of patch provided by Mike 
Franzen was undoubtly better, but (since he had no time to test it) it did 
not write the SACK changes back to mbuf. 

I have corrected and tested the code and  there is my proposal.
It works and changes the SACK values correctly.

The following things were changed:

1. I add additional variable "thoptlen" 
   meaning "tcp header options length"
It is used to store the length of options. It will be used at the end of 
pf_modulate_sack function:
+        if (copyback)
+                m_copyback(m, off + sizeof(*th), thoptlen, opts);
thoptlen is used instead of "olen" since olen variable gets changed and 
cannot be used in here.

It was the important thing to correct to make it work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ray Lai | 4 Jan 2006 17:07

Re: -Wall cleanup for vi

Hi,

This diff removes the ```name' might be used uninitialized in this
function'' warning.  If the variable ``name'' is used, it is either
set equal to the argument ``*namep'' or set to the character `1'.
This diff initialized ``name'' to `1' and removes the lines that
set ``name'' to `1'.

The warning comes from when vi copies into the unnamed buffer.  In
this case, ``name'' is not set to anything, but it is never used.

Please look at my previous diffs as well.  Thank you.

-Ray-

Index: common/cut.c
===================================================================
RCS file: /cvs/src/usr.bin/vi/common/cut.c,v
retrieving revision 1.8
diff -u -r1.8 cut.c
--- common/cut.c	17 Oct 2005 19:12:16 -0000	1.8
+++ common/cut.c	4 Jan 2006 15:54:20 -0000
 <at>  <at>  -73,7 +73,7  <at>  <at> 
 	int flags;
 {
 	CB *cbp;
-	CHAR_T name;
+	CHAR_T name = '1';	/* default numeric buffer */
 	recno_t lno;
 	int append, copy_one, copy_def;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray Lai | 4 Jan 2006 17:59

Re: -Wall cleanup for vi

On Wed, Jan 04, 2006 at 11:07:58AM -0500, Ray Lai wrote:
Hi,

This diff removes an unused variable from a macro and removes an
unused macro.  No binary change.

Please look at my previous diffs as well.  Thank you.

-Ray-

Index: common/util.h
===================================================================
RCS file: /cvs/src/usr.bin/vi/common/util.h,v
retrieving revision 1.2
diff -u -r1.2 util.h
--- common/util.h	29 Jan 2001 01:58:32 -0000	1.2
+++ common/util.h	4 Jan 2006 16:55:28 -0000
 <at>  <at>  -46,7 +46,7  <at>  <at> 
 	(((long)(min)) - (cur) <= (add))
 #define	NPFITS(max, cur, add)						\
 	(((unsigned long)(max)) - (cur) >= (add))
-#define	NADD_SLONG(sp, v1, v2)						\
+#define	NADD_SLONG(v1, v2)						\
 	((v1) < 0 ?							\
 	    ((v2) < 0 &&						\
 	    NNFITS(LONG_MIN, (v1), (v2))) ? NUM_UNDER : NUM_OK :	\
 <at>  <at>  -54,5 +54,3  <at>  <at> 
 	    (v2) > 0 &&							\
 	    NPFITS(LONG_MAX, (v1), (v2)) ? NUM_OK : NUM_OVER :		\
 	 NUM_OK)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Otto Moerbeek | 4 Jan 2006 20:53

Re: rthreads: plugging mem leaks

On Tue, 3 Jan 2006, Otto Moerbeek wrote:

> Hi,
> 
> One of the large missing pieces of the rthreads puzzle is cleaning up
> after a thread exits. 
> 
> This is all more complicated that you'd think since a thread may be
> referenced by pthread_join() or pthread_detach() _after_ it has exited.
> 
> Cleaning up stacks is even more nasty: the stack is needed to call
> threxit(). Cleaning up the stack cannot be done in the regular cleanup
> code, sice the we do not know if the threxit() has actually been
> completed.
> 
> Anyway, here's a diff to fix all this. It's nice to see the
> pthread_specific regress test first eat a lot of memory, and then
> giving it back piece by piece.
> 
> Thanks to Marco Hyman for providing some valuable hints.

A different version has been committed, not neading a separate reaper thread.

	-Otto
Permalink | Reply | 0 comments |
headers
RJH1896 | 4 Jan 2006 21:22
Picon
Favicon

BCM5701

I don't know how or why but after installing windows xp when I start the  
computer up I get a found new hardware device on my screen.I've tried to load it  
but it says installation problem. I need an Installation disk. will you tell 
me  how much $ it will cost.or if I can still get one. thanks  
_rjh1896 <at> aol.com_ (mailto:rjh1896 <at> aol.com)
Permalink | Reply | 0 comments |

Gmane