forwarding/ipfw/pf evolution (in pps) on -current
Hi all, here is the result of my simple-and-dummy bench script regarding forwarding/ipfw/pf performance evolution on -current on a single-core server with one flow only. It's the result of more than 810 bench tests (including reboot between each) done twice for validating my methodology. # Disclaimer # 1. It's not a "max performance" bench: The purpose is to graph the variation of the performance only. 2. I know that using a single-core server in 2013 is a stupid idea but it's all I've got on my lab :-( # Why all these benchs ? # I've found performance regression regarding packet forwarding/ipfw/pf speed on -current comparing to 9.1 on my old server. glebius@ ask me to do some bisection hunting on different -current revision for spotting the culprit commit. But as a lazy guy, in place of doing bisection, I've choose about 50 svn revision and graph them all: It's a lot's more easy to script this than a bisection algorithm :-) And the result is interesting… # The results # The gnuplot diagram in png format with some confirmed specifics spots is available here: http://gugus69.free.fr/freebsd/benchs/current/current-pps.png A confirmed spot is a measurable change between revision N-1 and revision N. => Remember that I'm used a single-core before reading the result! The "regression" of the new SMP pf is not really a regression: The system is now usable during this high PPS bench and it was not the case before this improvement. ## gnuplot data ## Available here: http://gugus69.free.fr/freebsd/benchs/current/plot/ It's the data and plot file used for generating the graph: You can use them for zooming on it. ## ministat data ## Available here: http://gugus69.free.fr/freebsd/benchs/current/ministat/ You can use it for comparing result between 2 revision, like as example: ministat -s 242160.ipfw 242161.ipfw ## raw data ## Outpout of pkg-gen during all tests: http://gugus69.free.fr/freebsd/benchs/current/raw/ ## nanobsd images # All binary mages used for these benchs are here: http://gugus69.free.fr/freebsd/benchs/current/nanobsd-images/ There is only one "full" image to be used for the first installation, and all other are "upgrade" image. They use the serial port as default console too. # Methodology used # ## First step: building a small lab ## I've used 3 old unused servers and a good switch: - One server as netmap pkt-gen packet generator (1.38Mpps of minimum size packet); - One server as netmap pkt-gen receiver; - One server with 2 NIC in the middle as a router/firewall, serial connection, and nanobsd image on it (very easy to upgrade): IBM eServer xSeries 306m with one core (Intel Pentium4 3.00GHz, hyper-threading disabled) and a dual NIC 82546GB connected to the PCI-X Bus; - a Cisco Catalyst switch for connecting all (its own statistics can be used as a tie breaker if I've got a doubt regarding the result given by netmap pkt-gen). All servers have another NIC for the admin network (bench script send SSH commands and nanobsd image upgrade over this dedicated NIC). I've used netmap pkt-gen for generating smallest packet size from the generator to the receiver like that: pkt-gen -i em0 -t 0 -l 42 -d 1.1.1.1 -D 00:0e:0c:de:45:df -s 2.2.2.2 -w 10 Results was collected on the pkt-gen receiver. ## Second step: building small nanobsd images ## Now we need lot's of small nanobsd images generated from the svn revision number selected for the bench: cf script [1]. About 50 revisions were selected between 236884 to 249506: Candidate chosen by reading the svn commit log. ## Third step: auto-bench script ## This auto-bench script [2] do these tasks: 1. Upgrading the server to the release to be tested; 2. Uploading configuration set to be tested (forwarding-only, ipfw or pf) & reboot; 3. Start the bench test, collecting the result, and reboot: 5 times for each configuration-set; 4Loop to next configuration set; 5. Loop to next release. ## Last step: converting result for ministat and gnuplot ## I've used a last script for interpreting the output of pkt-gen receiver for ministat and gnuplot [3]. Because I'm not sure if I've used the good method for preparing my data, here is how I've generated the ministat and gnuplot graph: For just one test, the output of pkt-gen in receive mode is lot's of lines like that: main [1085] 400198 pps main [1085] 400287 pps main [1085] 400240 pps main [1085] 400235 pps main [1085] 400245 pps ... I've calculated the median value [3] (thanks ministat) all these results: This give me only one number for the test. => I did the same for each of the 5 same bench tests (same configuration-set, just a reboot between them). And I've put these 5 numbers in the file named SVN-REV.CONFIG-SET. => From these 5 numbers, I've calculated the "median" value again: This give me a unique performance number that I've used as gnuplot data file. ## Bisection ## >From this first result, I've selected others svn revision to generated: The goal was to spot the exact commit tha
Re: forwarding/ipfw/pf evolution (in pps) on -current
Oliver, Great and impressive job. If I interpret the plot as is the result say (approximatly of course): 1. Forwarding using ipfw with single rule degrades ~25% the pps. 2. Forwarding with pf however gets ~50%+ of degredation if performance pps. 3. there some point of improved performance (without fw) that went down again somewhere before Clang got prod. 4. I think that the results don't necessarly can be translated to SMP versions because of scheduler, affinity issues. For now i would continue using ipfw :-) Sami On Apr 24, 2013 1:45 PM, "Olivier Cochard-Labbé" wrote: > Hi all, > > here is the result of my simple-and-dummy bench script regarding > forwarding/ipfw/pf performance evolution on -current on a single-core > server with one flow only. > It's the result of more than 810 bench tests (including reboot between > each) done twice for validating my methodology. > > # Disclaimer # > > 1. It's not a "max performance" bench: The purpose is to graph the > variation of the performance only. > 2. I know that using a single-core server in 2013 is a stupid idea but > it's all I've got on my lab :-( > > # Why all these benchs ? # > > I've found performance regression regarding packet forwarding/ipfw/pf > speed on -current comparing to 9.1 on my old server. > glebius@ ask me to do some bisection hunting on different -current > revision for spotting the culprit commit. > But as a lazy guy, in place of doing bisection, I've choose about 50 > svn revision and graph them all: It's a lot's more easy to script this > than a bisection algorithm :-) > And the result is interesting… > > # The results # > > The gnuplot diagram in png format with some confirmed specifics spots > is available here: > http://gugus69.free.fr/freebsd/benchs/current/current-pps.png > > A confirmed spot is a measurable change between revision N-1 and revision > N. > > => Remember that I'm used a single-core before reading the result! > The "regression" of the new SMP pf is not really a regression: The > system is now usable during this high PPS bench and it was not the > case before this improvement. > > ## gnuplot data ## > > Available here: http://gugus69.free.fr/freebsd/benchs/current/plot/ > It's the data and plot file used for generating the graph: You can use > them for zooming on it. > > ## ministat data ## > > Available here: http://gugus69.free.fr/freebsd/benchs/current/ministat/ > > You can use it for comparing result between 2 revision, like as example: > ministat -s 242160.ipfw 242161.ipfw > > ## raw data ## > > Outpout of pkg-gen during all tests: > http://gugus69.free.fr/freebsd/benchs/current/raw/ > > ## nanobsd images # > > All binary mages used for these benchs are here: > http://gugus69.free.fr/freebsd/benchs/current/nanobsd-images/ > > There is only one "full" image to be used for the first installation, > and all other are "upgrade" image. > They use the serial port as default console too. > > # Methodology used # > > ## First step: building a small lab ## > > I've used 3 old unused servers and a good switch: > - One server as netmap pkt-gen packet generator (1.38Mpps of minimum > size packet); > - One server as netmap pkt-gen receiver; > - One server with 2 NIC in the middle as a router/firewall, serial > connection, and nanobsd image on it (very easy to upgrade): IBM > eServer xSeries 306m with one core (Intel Pentium4 3.00GHz, > hyper-threading disabled) and a dual NIC 82546GB connected to the > PCI-X Bus; > - a Cisco Catalyst switch for connecting all (its own statistics can > be used as a tie breaker if I've got a doubt regarding the result > given by netmap pkt-gen). > > All servers have another NIC for the admin network (bench script send > SSH commands and nanobsd image upgrade over this dedicated NIC). > > I've used netmap pkt-gen for generating smallest packet size from the > generator to the receiver like that: > pkt-gen -i em0 -t 0 -l 42 -d 1.1.1.1 -D 00:0e:0c:de:45:df -s 2.2.2.2 -w 10 > Results was collected on the pkt-gen receiver. > > ## Second step: building small nanobsd images ## > > Now we need lot's of small nanobsd images generated from the svn > revision number selected for the bench: cf script [1]. > About 50 revisions were selected between 236884 to 249506: Candidate > chosen by reading the svn commit log. > > ## Third step: auto-bench script ## > > This auto-bench script [2] do these tasks: > 1. Upgrading the server to the release to be tested; > 2. Uploading configuration set to be tested (forwarding-only, ipfw > or pf) & reboot; > 3. Start the bench test, collecting the result, and reboot: 5 > times for each configuration-set; > 4Loop to next configuration set; > 5. Loop to next release. > > ## Last step: converting result for ministat and gnuplot ## > > I've used a last script for interpreting the output of pkt-gen > receiver for ministat and gnuplot [3]. > > Because I'm not sure if I've used the good method for preparing my > data, here is how I've generated the ministat and gnuplot
Re: forwarding/ipfw/pf evolution (in pps) on -current
On Wed, Apr 24, 2013 at 1:46 PM, Sami Halabi wrote: > Oliver, > Great and impressive job. Thanks, > 3. there some point of improved performance (without fw) that went down > again somewhere before Clang got prod. => Yes, I'm still working on detected the commit that create this degradation. > For now i would continue using ipfw :-) Don't use this bench for comparing pf and ipfw performance: Using the single parameter "small packet per second throughput" is not enough for comparing firewalls performance. If you read RFC3511 (Benchmarking Methodology for Firewall Performance) you will notice that we need to compare lot's more parameters like: - IP throughput - Concurrent TCP Connection Capacity - Maximum TCP Connection Establishment Rate - Maximum TCP Connection Tear Down Rate - Denial Of Service Handling - HTTP Transfer Rate - Maximum HTTP Transaction Rate - Illegal Traffic Handling - IP Fragmentation Handling - Latency - etc... And I want to add another: High availability feature like with pfsync :-) Regards, Olivier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding/ipfw/pf evolution (in pps) on -current
On 24.04.2013 12:45, Olivier Cochard-Labbé wrote: Hi all, here is the result of my simple-and-dummy bench script regarding forwarding/ipfw/pf performance evolution on -current on a single-core server with one flow only. It's the result of more than 810 bench tests (including reboot between each) done twice for validating my methodology. Thanks for your excellent work in doing this benchmark time-series, - One server with 2 NIC in the middle as a router/firewall, serial connection, and nanobsd image on it (very easy to upgrade): IBM eServer xSeries 306m with one core (Intel Pentium4 3.00GHz, hyper-threading disabled) and a dual NIC 82546GB connected to the PCI-X Bus; however I want to point out that the Pentium4 has about the worst lock overhead of all cpu architectures, even on UP. This may cause certain changes to look much worse than they are on currently popular architectures. For an estimate and time-series comparison your bench test is very helpful though. -- Andre ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips64/mips
TB --- 2013-04-24 12:49:07 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-24 12:49:07 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-24 12:49:07 - starting HEAD tinderbox run for mips64/mips TB --- 2013-04-24 12:49:07 - cleaning the object tree TB --- 2013-04-24 12:50:03 - /usr/local/bin/svn stat /src TB --- 2013-04-24 12:50:07 - At svn revision 249829 TB --- 2013-04-24 12:50:08 - building world TB --- 2013-04-24 12:50:08 - CROSS_BUILD_TESTING=YES TB --- 2013-04-24 12:50:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-24 12:50:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-24 12:50:08 - SRCCONF=/dev/null TB --- 2013-04-24 12:50:08 - TARGET=mips TB --- 2013-04-24 12:50:08 - TARGET_ARCH=mips64 TB --- 2013-04-24 12:50:08 - TZ=UTC TB --- 2013-04-24 12:50:08 - __MAKE_CONF=/dev/null TB --- 2013-04-24 12:50:08 - cd /src TB --- 2013-04-24 12:50:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Apr 24 12:50:12 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/kld.c cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/kthr.c cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/trgt.c cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:122: error: 'struct trapframe' has no member named 't4' /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:123: error: 'struct trapframe' has no member named 't5' /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:124: error: 'struct trapframe' has no member named 't6' /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:125: error: 'struct trapframe' has no member named 't7' *** [trgt_mips.o] Error code 1 Stop in /src/gnu/usr.bin/gdb/kgdb. *** [all] Error code 1 Stop in /src/gnu/usr.bin/gdb. *** [all] Error code 1 Stop in /src/gnu/usr.bin. *** [all] Error code 1 Stop in /src/gnu. *** [gnu.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-24 13:33:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 20
'service named reload' with non-default system directories.
Hi
I often run named outside of the system default directories so that
amongst other things a mergemaster fumble doesn't break my name
servers. This however breaks rndc because it is not imbued with
the clue of where to find its key.
/etc/rc.d/named does create the key file in the correct place
according to the configured chroot directory. The reload section
just doesn't tell rndc where to find it.
Can I suggest for a minimal change:
--- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
+++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
@@ -109,7 +109,7 @@
named_reload()
{
- ${command%/named}/rndc reload
+ ${command%/named}/rndc -k ${named_confdir}/rndc.key reload
}
find_pidfile()
A more invasive change:
The bind9 reference suggests that named loading rndc.key is for
backwards compatibility.
"Since the rndc.key feature is only intended to allow the
backward-compatible usage of BIND 8 configuration files, this
feature does not have a high degree of configurability. You
cannot easily change the key name or the size of the secret, so
you should make a rndc.conf with your own key if you wish to
change those things.
So, I 'include "path/to/rndc.key";' in named.conf, add a controls
section that uses this named key and I use the following rndc.conf:
---named.conf---
include "/etc/namedb/rndc.key";
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; };
};
---named.conf---
---rndc.conf---
include "/etc/namedb/rndc.key";
options {
default-server localhost;
default-key rndc-key;
};
server localhost {
key rndc-key;
};
---rndc.conf---
And the following version of the above patch:
--- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
+++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
@@ -109,7 +109,7 @@
named_reload()
{
- ${command%/named}/rndc reload
+ ${command%/named}/rndc -c ${named_confdir}/rndc.conf reload
}
find_pidfile()
this will allow the rc system to reload and stop named (without a
kill) no matter what the configured chroot is.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 'service named reload' with non-default system directories.
On Wed, 2013-04-24 at 16:35 +0200, Ian FREISLICH wrote:
>
> --- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
> +++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
> @@ -109,7 +109,7 @@
>
> named_reload()
> {
> - ${command%/named}/rndc reload
> + ${command%/named}/rndc -k ${named_confdir}/rndc.key reload
> }
>
> find_pidfile()
> So, I 'include "path/to/rndc.key";' in named.conf, add a controls
> section that uses this named key and I use the following rndc.conf:
>
> ---named.conf---
> include "/etc/namedb/rndc.key";
>
> controls {
> inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; };
> };
> ---named.conf---
>
> ---rndc.conf---
> include "/etc/namedb/rndc.key";
>
> options {
> default-server localhost;
> default-key rndc-key;
> };
>
> server localhost {
> key rndc-key;
> };
> ---rndc.conf---
>
> And the following version of the above patch:
>
> --- /usr/src/etc/rc.d/named 2013-04-15 20:17:58.0 +0200
> +++ /etc/rc.d/named 2013-04-24 16:16:52.0 +0200
> @@ -109,7 +109,7 @@
>
> named_reload()
> {
> - ${command%/named}/rndc reload
> + ${command%/named}/rndc -c ${named_confdir}/rndc.conf reload
> }
>
> find_pidfile()
>
> this will allow the rc system to reload and stop named (without a
> kill) no matter what the configured chroot is.
>
> Ian
>
Would we need a change to /etc/defaults/rc.conf to set ${named_confdir}
to the default location if not set?
Also, there already appears to be a ${named_conf} that points to
whatever named.conf specified (defaults to /etc/namedb/named.conf). Is
this complementary to what you're poking at?
Sean
signature.asc
Description: This is a digitally signed message part
Re: 'service named reload' with non-default system directories.
Sean Bruno wrote:
> Would we need a change to /etc/defaults/rc.conf to set ${named_confdir}
> to the default location if not set?
I'm not sure. It's derived:
load_rc_config $name
# Updating the following variables requires that rc.conf be loaded first
#
required_dirs="$named_chrootdir"# if it is set, it must exist
named_confdir="${named_chrootdir}${named_conf%/*}"
I don't think that I did a particularly good job of making it work
for all instances. It's more of an opening move to get this working
properly wherever the admin chooses to put the named chroot. I'm
still expecting comments from Doug Barton.
> Also, there already appears to be a ${named_conf} that points to
> whatever named.conf specified (defaults to /etc/namedb/named.conf). Is
> this complementary to what you're poking at?
This is specifically rndc (not named) that fails to find its key
or config if you choose to use a chrootdir that isn't the default.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@
On Tue, 2013-04-23 at 21:03 +0200, Dimitry Andric wrote: > On Apr 17, 2013, at 21:16, Jung-uk Kim wrote: > > On 2013-04-17 06:07:47 -0400, Dimitry Andric wrote: > >> On Apr 17, 2013, at 07:31, Jan Beich wrote: > >>> Dimitry Andric writes: On Apr 16, 2013, at > >>> 00:42, Jan Beich wrote: > >> ... > > Maybe -O3 overoptimizes regex in libc e.g., > > > > $ echo '#if @GNULIB_EUIDACCESS@' | sed > > 's/@GNULIB_EUIDACCESS@/0/' #if @GNULIB_EUIDACCESS@ > > > > $ echo 'xxx' | sed > > 's/xxx//' xxx > > How did you arrive at this result? > >>> > >>> 1/ chroot into poudriere jail for /head amd64 2/ echo CFLAGS+=-O3 > > /etc/make.conf 3/ make -j2 (in /usr/src/lib/libc) 4/ prepend > >>> LD_LIBRARY_PATH=. before sed(1) 5/ rebuild regcomp.o, regcomp.So > >>> with -O2 to confirm > >> > >> I have been able to reproduce this on amd64, with -O3, but not on > >> i386. It seems regcomp() is either miscompiled at -O3, or it > >> contains some bug triggered only by the vectorizer. I am still > >> investigating. > > ... > > > > With "-fno-vectorize", this problem doesn't seem to happen. > > After some more investigation, I submitted LLVM PR 15830, with a test > case reduced from our regcomp.c. It got diagnosed and fixed pretty > quickly, and I have pulled in the fix in r249817. Please verify it, by > rebuilding libc with your original -O3 settings; the sed commands listed > above should now work correctly. Both the ports devel/libiconv and graphics/jasper do not show the reported error anymore after this patch! Thanks for helping fixing this that fast! With regards, Oliver signature.asc Description: This is a digitally signed message part
Re: panic on a NULL turnstile on boot on r249810
On Wed, Apr 24, 2013 at 12:25:02AM +0400, Gleb Smirnoff wrote: T> just upgraded from r245115 to r249810 and now box reliably panics on T> boot a second after mounting root. I've nailed it down. It is a stack buffer overflow in the nvidia-driver. I've submitted patch to port maintainer. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding/ipfw/pf evolution (in pps) on -current
On 4/24/13 6:45 PM, Olivier Cochard-Labbé wrote: Hi all, here is the result of my simple-and-dummy bench script regarding forwarding/ipfw/pf performance evolution on -current on a single-core server with one flow only. It's the result of more than 810 bench tests (including reboot between each) done twice for validating my methodology. very cool bet that was fun.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: forwarding/ipfw/pf evolution (in pps) on -current
On 4/24/2013 6:45 AM, Olivier Cochard-Labbé wrote: > # Why all these benchs ? # > > I've found performance regression regarding packet forwarding/ipfw/pf > speed on -current comparing to 9.1 on my old server. BTW, how much of a drop in performance as compared to 9.1 ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips64/mips
TB --- 2013-04-25 00:07:39 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-25 00:07:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-25 00:07:39 - starting HEAD tinderbox run for mips64/mips TB --- 2013-04-25 00:07:39 - cleaning the object tree TB --- 2013-04-25 00:08:40 - /usr/local/bin/svn stat /src TB --- 2013-04-25 00:08:43 - At svn revision 249844 TB --- 2013-04-25 00:08:44 - building world TB --- 2013-04-25 00:08:44 - CROSS_BUILD_TESTING=YES TB --- 2013-04-25 00:08:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-25 00:08:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-25 00:08:44 - SRCCONF=/dev/null TB --- 2013-04-25 00:08:44 - TARGET=mips TB --- 2013-04-25 00:08:44 - TARGET_ARCH=mips64 TB --- 2013-04-25 00:08:44 - TZ=UTC TB --- 2013-04-25 00:08:44 - __MAKE_CONF=/dev/null TB --- 2013-04-25 00:08:44 - cd /src TB --- 2013-04-25 00:08:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Apr 25 00:08:49 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/kld.c cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/kthr.c cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/trgt.c cc -O -pipe -G0 -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -I. -I/src/gnu/usr.bin/gdb/kgdb/../arch/mips -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/mips -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:122: error: 'struct trapframe' has no member named 't4' /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:123: error: 'struct trapframe' has no member named 't5' /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:124: error: 'struct trapframe' has no member named 't6' /src/gnu/usr.bin/gdb/kgdb/trgt_mips.c:125: error: 'struct trapframe' has no member named 't7' *** [trgt_mips.o] Error code 1 Stop in /src/gnu/usr.bin/gdb/kgdb. *** [all] Error code 1 Stop in /src/gnu/usr.bin/gdb. *** [all] Error code 1 Stop in /src/gnu/usr.bin. *** [all] Error code 1 Stop in /src/gnu. *** [gnu.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-25 00:52:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 20
Re: forwarding/ipfw/pf evolution (in pps) on -current
On Wed, Apr 24, 2013 at 1:46 PM, Sami Halabi wrote: > 3. there some point of improved performance (without fw) that went down > again somewhere before Clang got prod. Found it ! It's commit 242402: "Rework the known mutexes..." ministat -s 242401.forwarding 242402.forwarding x 242401.forwarding + 242402.forwarding +---+ |+ | |+ + + + x xx x x| | |A| | | |_A_M___| | +---+ N Min MaxMedian AvgStddev x 5417527420242418902419074 1049.7974 + 5402211404828404096403689 1237.6696 Difference at 95.0% confidence -15385 +/- 1673.69 -3.67119% +/- 0.399377% (Student's t, pooled s = 1147.58) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
