On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
TB --- 2010-03-21 03:05:00 - tinderbox 2.6 running on
freebsd-current.sentex.ca
TB --- 2010-03-21 03:05:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-21 03:05:00 - cleaning the object tree
TB ---
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@wwu.de
wrote:
ok. i think i finally solved this riddle. the cause for the problem
seems to
have been my CPUTYPE in /etc/make.conf. it is set to 'native'.
actually i've
been using the
On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best alexbes...@wwu.de wrote:
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@wwu.de
wrote:
ok. i think i finally solved this riddle. the cause for the problem
seems to
have been my CPUTYPE in
on 21/03/2010 13:43 Garrett Cooper said the following:
Works for me *shrugs*:
$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719
Garrett Cooper schrieb am 2010-03-21:
On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best alexbes...@wwu.de
wrote:
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
alexbes...@wwu.de
wrote:
ok. i think i finally solved this riddle. the cause for the
it would be nice if people with arch i386 and amd64 could try to
reproduce this (i believe the other archs don't support CPUTYPE=native).
again the easiest way to trigger this (you don't need to edit your
/etc/make.conf for this) should be running:
gcc -v -x c -E -mtune=native
Pegasus Mc Cleaft schrieb am 2010-03-21:
it would be nice if people with arch i386 and amd64 could try to
reproduce this (i believe the other archs don't support
CPUTYPE=native).
again the easiest way to trigger this (you don't need to edit
your
/etc/make.conf for this) should be
on 21/03/2010 14:35 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 13:43 Garrett Cooper said the following:
Works for me *shrugs*:
$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21
Using built-in specs.
Target: amd64-undermydesk-freebsd
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 14:35 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 13:43 Garrett Cooper said the following:
Works for me *shrugs*:
$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21
Using built-in specs.
On Sun, 21 Mar 2010 13:43:52 +0100 (CET)
Alexander Best alexbes...@wwu.de wrote:
Pegasus Mc Cleaft schrieb am 2010-03-21:
it would be nice if people with arch i386 and amd64 could try to
reproduce this (i believe the other archs don't support
CPUTYPE=native).
again the easiest
On Sun, 21 Mar 2010 14:03:04 +0100
Gary Jennejohn gary.jennej...@freenet.de wrote:
On Sun, 21 Mar 2010 13:43:52 +0100 (CET)
Alexander Best alexbes...@wwu.de wrote:
Pegasus Mc Cleaft schrieb am 2010-03-21:
it would be nice if people with arch i386 and amd64 could try to
reproduce
Julian Elischer wrote:
In the Fusion-io driver we find that the limiting factor is not the
size of MAXPHYS, but the fact that we can not push more than
170k tps through geom. (in my test machine. I've seen more on some
beefier machines), but that is only a limit on small transacrtions,
or in
Ivan Voras wrote:
Julian Elischer wrote:
You can get better throughput by using TSC for timing because the geom
and devstat code does a bit of timing.. Geom can be told to turn off
it's timing but devstat can't. The 170 ktps is with TSC as timer,
and geom timing turned off.
I see. I just
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be easy to spawn more g_* threads (and,
barring specific class behaviour, it has a fair chance of working out of
the box) but the incoming queue will need to also be broken up for
greater
on 21/03/2010 14:53 Alexander Best said the following:
*lol* sorry. ;)
No worries.
BTW, when that rash happens, are you able to examine the core with gdb?
Is it possible to examine values of 's' and 'p' in strlen?
--
Andriy Gapon
___
TB --- 2010-03-21 13:35:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-21 13:35:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-21 13:35:00 - cleaning the object tree
TB --- 2010-03-21 13:35:25 - cvsupping the source tree
TB --- 2010-03-21 13:35:25 -
On 2010-03-21 14:08, Gary Jennejohn wrote:
CPUTYPE=native
CFLAGS=-O2 -fno-strict-aliasing -pipe -s
btw: what's the -s switch doing?
It silences make. See the man page. It's useful because basically only
errors are emitted.
Oops. That's wrong. I got confused. I'd like to know that
Alexander Motin wrote:
Julian Elischer wrote:
In the Fusion-io driver we find that the limiting factor is not the
size of MAXPHYS, but the fact that we can not push more than
170k tps through geom. (in my test machine. I've seen more on some
beefier machines), but that is only a limit on small
Andriy Gapon wrote:
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be easy to spawn more g_* threads (and,
barring specific class behaviour, it has a fair chance of working out of
the box) but the incoming queue will need to also be broken
On Mar 21, 2010, at 8:05 AM, Alexander Motin wrote:
Ivan Voras wrote:
Julian Elischer wrote:
You can get better throughput by using TSC for timing because the geom
and devstat code does a bit of timing.. Geom can be told to turn off
it's timing but devstat can't. The 170 ktps is with TSC as
m
On Mar 21, 2010, at 8:56 AM, Andriy Gapon wrote:
on 21/03/2010 16:05 Alexander Motin said the following:
Ivan Voras wrote:
Hmm, it looks like it could be easy to spawn more g_* threads (and,
barring specific class behaviour, it has a fair chance of working out of
the box) but the incoming
On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote:
Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of an
odd number less than 512k. For the purpose of benchmarking against these
OS's, having comparable capabilities is essential; Linux easily beats FreeBSD
in the
On Mar 20, 2010, at 1:26 PM, Alexander Motin wrote:
Scott Long wrote:
On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote:
Diminishing returns get hit pretty quickly with larger MAXPHYS values.
As long as the I/O can be pipelined the reduced transaction rate
becomes less interesting
On Mar 21, 2010, at 10:30 AM, Ulrich Spörlein wrote:
On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote:
Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of an
odd number less than 512k. For the purpose of benchmarking against these
OS's, having comparable capabilities is
[CC trimmed]
On Sun, 21.03.2010 at 10:39:10 -0600, Scott Long wrote:
On Mar 21, 2010, at 10:30 AM, Ulrich Spörlein wrote:
On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote:
Windows has a MAXPHYS equivalent of 1M. Linux has an equivalent of an
odd number less than 512k. For the
Scott Long wrote:
On Mar 20, 2010, at 1:26 PM, Alexander Motin wrote:
As you should remember, we have made it in such way, that all unchecked
drivers keep using DFLTPHYS, which is not going to be changed ever. So
there is no problem. I would more worry about non-CAM storages and above
stuff,
On Mar 21, 2010, at 10:53 AM, Ulrich Spörlein wrote:
[CC trimmed]
On Sun, 21.03.2010 at 10:39:10 -0600, Scott Long wrote:
On Mar 21, 2010, at 10:30 AM, Ulrich Spörlein wrote:
On Sat, 20.03.2010 at 12:17:33 -0600, Scott Long wrote:
Windows has a MAXPHYS equivalent of 1M. Linux has an
On Sat, Mar 20, 2010 at 08:53:37PM +, Anton Shterenlikht wrote:
On Sat, Mar 20, 2010 at 03:44:46PM +, Anton Shterenlikht wrote:
On Sat, Mar 20, 2010 at 07:27:43AM -0400, jhell wrote:
On Fri, 19 Mar 2010 17:15, Anton Shterenlikht wrote:
In Message-Id:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 14:53 Alexander Best said the following:
*lol* sorry. ;)
No worries.
BTW, when that rash happens, are you able to examine the core with
gdb?
Is it possible to examine values of 's' and 'p' in strlen?
'p' is not available. i guess because
Scott Long wrote:
I agree that more threads just creates many more race
complications. Even if it didn't, the storage driver is a
serialization point; it doesn't matter if you have a dozen g_*
threads if only one of them can be in the top half of the driver at
a time. No amount of
On Fri, Mar 19, 2010 at 7:09 AM, David Wolfskill da...@catwhisker.org wrote:
On Fri, Mar 19, 2010 at 01:09:11PM +, Rui Paulo wrote:
...
Do you all have either out-of-tree modules or modules that you did not
re-build when re-compiling your kernel?
I have in-tree modules, but I tried a
Marcel
On Sun, Mar 21, 2010 at 06:22:14PM +, Anton Shterenlikht wrote:
An update:
1. reinstalled from 8.0-CURRENT-200906
2. installed the ports tree via csup(1)
3. installed svn(1) from ports
4. updated src with svn.
Both svn and csup worked fine here.
5. rebuilt and
on 21/03/2010 20:46 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 14:53 Alexander Best said the following:
*lol* sorry. ;)
No worries.
BTW, when that rash happens, are you able to examine the core with
gdb?
Is it possible to examine values of 's' and
On Mar 21, 2010, at 1:27 PM, Anton Shterenlikht wrote:
It seems the problems I've had in the last
several days with ldd/csup/svn/rm have the
same root cause.
I'm aware of the issue. Give me a few days to fix it. I have a
fix under test, but it exposes other problems...
--
Marcel Moolenaar
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 20:46 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 14:53 Alexander Best said the following:
*lol* sorry. ;)
No worries.
BTW, when that rash happens, are you able to examine the core with
gdb?
On Sun, Mar 21, 2010 at 8:35 AM, Dimitry Andric dimi...@andric.com wrote:
On 2010-03-21 14:08, Gary Jennejohn wrote:
CPUTYPE=native
CFLAGS=-O2 -fno-strict-aliasing -pipe -s
btw: what's the -s switch doing?
It silences make. See the man page. It's useful because basically
only
errors
On Sun, Mar 21, 2010 at 2:11 PM, Alexander Best alexbes...@wwu.de wrote:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 20:46 Alexander Best said the following:
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 14:53 Alexander Best said the following:
*lol* sorry. ;)
No worries.
on 21/03/2010 23:11 Alexander Best said the following:
*hehe* that makes more sense. well i already sent you lp. unfortunately str is
not available to gdb:
(gdb) print str
Variable str is not available.
In cases like this sometimes the argument is still available for examination as
a
Andriy Gapon schrieb am 2010-03-21:
on 21/03/2010 23:11 Alexander Best said the following:
*hehe* that makes more sense. well i already sent you lp.
unfortunately str is
not available to gdb:
(gdb) print str
Variable str is not available.
In cases like this sometimes the argument is
On Sun, 21 Mar 2010 07:00, alexbestms@ wrote:
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@wwu.de
wrote:
ok. i think i finally solved this riddle. the cause for the problem
seems to
have been my CPUTYPE in /etc/make.conf. it is set to
On Sun, 21 Mar 2010 10:04, mav@ wrote:
Julian Elischer wrote:
In the Fusion-io driver we find that the limiting factor is not the
size of MAXPHYS, but the fact that we can not push more than
170k tps through geom. (in my test machine. I've seen more on some
beefier machines), but that is only
TB --- 2010-03-22 00:05:01 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-22 00:05:01 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-22 00:05:01 - cleaning the object tree
TB --- 2010-03-22 00:05:26 - cvsupping the source tree
TB --- 2010-03-22 00:05:26 -
On Sun, 21 Mar 2010 20:54, jhell@ wrote:
On Sun, 21 Mar 2010 10:04, mav@ wrote:
Julian Elischer wrote:
In the Fusion-io driver we find that the limiting factor is not the
size of MAXPHYS, but the fact that we can not push more than
170k tps through geom. (in my test machine. I've seen more
Dear all,
I would like to remind you that the next round of status reports
covering the first quarter of 2010 is due on April 15th, 2010. This
initiative is very welcome in our community. Therefore, I would like to
ask you to submit your status reports as soon as possible, so that we
can
jhell wrote:
On Sun, 21 Mar 2010 20:54, jhell@ wrote:
I played with it on one re-compile of a kernel and for the sake of it
DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash
dump to be performed upon request (reboot -d) due to the boundary
being hit for DMA which is 65536.
45 matches
Mail list logo
