TB --- 2012-04-24 03:49:41 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-04-24 03:49:41 - 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 ---
On Mon, Apr 23, 2012 at 08:17:40PM +0800, r...@9du.org wrote:
i think this head.diff may be is old!
it is, definitely time to remove it since the code
has been merged.
cheers
luigi
in diff
+#ifdef DEV_NETMAP
+ if (slot) {
+ netmap_load_map(txr-txtag, txbuf-map,
+ NMB(slot),
On 19.04.2012 22:46, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code
On Tue, Apr 24, 2012 at 03:16:48PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend
From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i remember well),
but there was a large gain with multiple concurrent processes.
Yes, that sounds about right when we did the tests a
On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing qing...@bluecoat.com wrote:
From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i remember well),
but there was a large gain with multiple
On Tue, Apr 24, 2012 at 5:03 PM, K. Macy km...@freebsd.org wrote:
On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing qing...@bluecoat.com wrote:
From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time,
TB --- 2012-04-24 13:01:51 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-04-24 13:01:51 - 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 ---
On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote:
From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i remember well),
but there was a large gain with multiple concurrent
On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote:
From previous tests, the difference between flowtable and
routing table was small with a single process (about 5% or 50ns
in the total packet processing time, if i
make -j4 buildworld error
--
World build started on Tue Apr 24 21:32:26 CST 2012
--
--
Rebuilding the temporary
I have a patch that has been sitting around for a long time due to
review cycle latency that caches a pointer to the rtentry (and
llentry) in the the inpcb. Before each use the rtentry is checked
against a generation number in the routing tree that is incremented on
every routing table
Yup, all good points. In fact we have considered all of these while doing
the work. In case you haven't seen it already, we did write about these
issues in our paper and how we tried to address those, flow-table was one
of the solutions.
http://dl.acm.org/citation.cfm?id=1592641
--Qing
I have a patch that has been sitting around for a long time due to
review cycle latency that caches a pointer to the rtentry (and
llentry) in the the inpcb. Before each use the rtentry is checked
against a generation number in the routing tree that is incremented
on
every routing
On Sun, Apr 22, 2012 at 09:06:18AM -0700, Garrett Cooper wrote:
On 4/20/2012 5:16 AM, Jan Sieka wrote:
I can't build world from recent sources (HEAD as of 2012.04.19 11:06:48
UTC) on a machine running FreeBSD 7.3.
...
Ugh. The usecase (that's now broken) is that Jan from Semihalf might
=== usr.bin/file (all)
/usr/bin/clang -O2 -pipe -DMAGIC='/usr/share/misc/magic'
-DHAVE_CONFIG_H -I/usr/src/usr.bin/file/../../lib/libmagic -std=gnu99
-Qunused-arguments -fstack-protector -Wsystem-headers -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes
I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine and
see poor
scalability of pmap/mtx -- more then 50% cpu spend on system time.
pmcstat:
@ CPU_CLK_UNHALTED_CORE [194841 samples]
42.65% [83102]_mtx_lock_sleep @ /boot/kernel/kernel
40.97% [34051] pmap_enter
Known problem. There is an open disagreement about how to improve the
granularity of locking in pmap.
-Kip
On Tue, Apr 24, 2012 at 9:14 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine
and see poor
scalability of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
vfscanf(3) in HEAD (r234606) segfaults when compiled with clang. For
instance, here is a call made in cmake which crashes:
fscanf(f, %*[^\n]\n);
The same libc, compiled with GCC, doesn't segfault.
When it encounters a character
On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote:
Known problem. There is an open disagreement about how to improve the
granularity of locking in pmap.
split locking to process-specific information and global information?
use lock-free lists (i see TAILQ_INSERT_TAIL in pmap_enter)?
No. I developed a patch from Jeffr that pushed the vm_page_lock array
down in to the machine dependent code, replacing most of the uses of
the single vm_page_queue_lock. However, alc doesn't like the design
and has not proposed an alternative.
-Kip
On Tue, Apr 24, 2012 at 10:36 PM, Slawa
On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:
No. I developed a patch from Jeffr that pushed the vm_page_lock array
down in to the machine dependent code, replacing most of the uses of
the single vm_page_queue_lock. However, alc doesn't like the design
and has not proposed an
It's a bit dated at this point. Nonetheless, when gitorious is able to
give something other than 503 to my search queries I'll post it.
On Tue, Apr 24, 2012 at 10:45 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:
No. I developed a patch
You can try these. Your mileage *will* vary.
https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_release_8_1_0_page_lock
https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_page_lock
On Tue, Apr 24, 2012 at 10:51 PM, K. Macy km...@freebsd.org wrote:
It's a bit
On 24. Apr 2012, at 17:42 , Li, Qing wrote:
I have a patch that has been sitting around for a long time due to
review cycle latency that caches a pointer to the rtentry (and
llentry) in the the inpcb. Before each use the rtentry is checked
against a generation number in the routing tree
25 matches
Mail list logo
