-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Claus Guttesen wrote:
I have read all related threads about performance problems with multi
core systems but still have no idea what to do to make thinks better.
Below are results of testing postgresql on HP DL380G5 using sysbench.
The results are
Miroslav Lachman wrote:
Oliver Fromme wrote:
if [ -z $SHELL -o ! -x $jail_path/$SHELL ]; then
login_shell=$SHELL
else
login_shell=/bin/sh
fi
Ian Smith brought to my attention that I got the logic
reversed in the if statement. He suggested to
Brian [EMAIL PROTECTED] wrote:
Joshua Coombs wrote:
For a very short while with 6.0 I was tweaking the kernel to detect
386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok
luck. I've now got a Cyrix 486DrX-2 66 installed in place of my
Am386DX-40, which supports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Krassimir Slavchev wrote:
Hello,
I have read all related threads about performance problems with multi
core systems but still have no idea what to do to make thinks better.
Below are results of testing postgresql on HP DL380G5 using sysbench.
was just experimenting with zfs on a spare slice on the disc - this may all
be entirely my fault for doing it worng, if so please tell me, but I
appear to be gettign a zfs pool ounted on reboot but with none of the
data appearing in it!
what I did:
1) take a space slice, only got one partition
I would like to request your opinion on the following proposal:
1. introduce new scsi_sense_action_qualifier value
SSQ_PRINT_SENSE_VERBOSE, which would mean that detailed command and
response information is to be printed only if bootverbose==1;
2. introduce new define SS_FATAL_NORMAL with value
heh I had the same prob a couple days back. Check the archives last
week, 10DEC07 Re: Various Issues with 7.0-BETA4
Step by step directions on how to fix
___
freebsd-stable@freebsd.org mailing list
heh I had the same prob a couple days back. Check the archives last
week, 10DEC07 Re: Various Issues with 7.0-BETA4
actually, it wsa that thread which motivated me to experiment ... and
I was thinking all along must remember to add zfs to loader.conf to
avoid that. Of course I then forgot to
O.K., even odder - it seems that something is creating a real '/tank'
directory in '/' for some reaosn, but not mounting the filesystems onto
it. when I reboot I get this:
# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
Are you sure that the settitle call is disabled on FreeBSD?
On 12/20/07, Krassimir Slavchev [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have read all related threads about performance problems with multi
core systems but still have no idea what to do to
* David G Lawrence [EMAIL PROTECTED] [071219 09:12] wrote:
Try it with find / -type f /dev/null to duplicate the problem
almost
instantly.
I was able to verify last night that (cd /; tar -cpf -) all.tar would
trigger the problem. I'm working getting a test running with
David's
Unfortunately, the version of the patch that I sent out isn't going to
help your problem. It needs to yield at the top of the loop, but vp isn't
necessarily valid after the wakeup from the msleep. That's a problem that
I'm having trouble figuring out a solution to - the solutions that
* David G Lawrence [EMAIL PROTECTED] [071221 15:42] wrote:
Unfortunately, the version of the patch that I sent out isn't going to
help your problem. It needs to yield at the top of the loop, but vp isn't
necessarily valid after the wakeup from the msleep. That's a problem that
I'm
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the problem, once you reach a certain point, the
system slows down *every* 30.999 seconds. Now, it's possible for the
The uio_yield() idea did not work. Still have the same 31 second
interval
packet loss.
Is it safe to assume the vp will be valid after a msleep() or
uio_yield()? If
so can we do something a little different:
Currently:
/* this takes too long when list is large */
MNT_VNODE_FOREACH(vp,
On Fri, Dec 21, 2007 at 05:43:09PM -0800, David Schwartz wrote:
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the problem, once you reach a certain point, the
Another attempt to use USB-storage with FreeBSD, another moment of
hair-pulling frustration.
I attach the card-reader with the media card already inserted (detection of
card-insertion has not worked in a long time, if ever).
The disk appears:
umass1: Genesys USB Reader, rev
On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote:
The uio_yield() idea did not work. Still have the same 31 second
interval packet loss.
What patch you have used ?
Lets check whether the syncer is the culprit for you.
Please, change the value of the syncdelay at the
On Fri, Dec 21, 2007 at 04:24:32PM -0800, Alfred Perlstein wrote:
* David G Lawrence [EMAIL PROTECTED] [071221 15:42] wrote:
Unfortunately, the version of the patch that I sent out isn't going
to
help your problem. It needs to yield at the top of the loop, but vp
isn't
I will need to build several Web caches over the next few months,
and just took advantage of the Christmas lull (and a snowy day,
when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how
it will perform at this task. I built up a 4 core FreeBSD box, and
asked a friend who's a Linux
On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote:
The uio_yield() idea did not work. Still have the same 31 second
interval packet loss.
What patch you have used ?
This is hand applied from the diff you sent December 19,
What patch you have used ?
This is hand applied from the diff you sent December 19, 2007 1:24:48
PM EST
Mark, try the previos patch from Kostik - the one that does the one
tick msleep. I think you'll find that that one does work. The likely
problem with the second version is that
On Sat, Dec 22, 2007 at 01:28:31AM -0500, Mark Fullmer wrote:
On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote:
Lets check whether the syncer is the culprit for you.
Please, change the value of the syncdelay at the sys/kern/vfs_subr.c
around the line 238 from 30 to some other value, e.g.,
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the problem, once you reach a certain point, the
system slows down *every* 30.999 seconds. Now, it's possible for the
As Bruce Evans noted, there is a vfs_msync() that do almost the same
traversal of the vnodes. It was missed in the previous patch. Try this one.
I forgot to comment on that when Bruce pointed that out. My solution
has been to comment out the call to vfs_msync. :-) It comes into play
when you
Can you use a placeholder vnode as a place to restart the scan?
you might have to mark it special so that other threads/things
(getnewvnode()?) don't molest it, but it can provide for a convenient
restart point.
That was one of the solutions that I considered and rejected since
26 matches
Mail list logo
