shes.
The (asynchronous) resolving of the names start in line 3876 of
ntp_config.c:
getaddrinfo_sometime(curr_peer->addr->address,
If we put the mlockall() call directly before this line, the
crash is gone.
Maybe you want to play around with rlimit, CNAMES, IPs and
so on...
-Andre
Anyone
On 26.08.2013 15:43, Roger Pau Monné wrote:
On 26/08/13 15:22, Andre Oppermann wrote:
On 26.08.2013 13:02, Roger Pau Monne wrote:
r254804 and r254807 changed the types of some of the members of the
mbuf struct, and introduced some compile time errors in netback
debug messages that prevented
ghtly different way just
before I saw your email.
There's a dedicated m_print() function upcoming that can/should replace all
those hand-grown variants.
--
Andre
Cc: an...@freebsd.org
---
sys/dev/xen/netback/netback.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -
l packet header parsing from the drivers for offload setup.
Others:
Mbuf initialization is unified through m_init() and m_pkthdr_init() to avoid
duplication. m_free_fast() is removed for lack of usage.
Patch is available here:
http://people.freebsd.org/~andre/mbuf-adjustments-20130821.dif
way to shutdown the ithread.
Yes, when done a well-tested, stable and performant template will be provided.
--
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"
On 05.08.2013 23:53, Luigi Rizzo wrote:
On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote:
On 05.08.2013 19:36, Luigi Rizzo wrote:
...
[picking a post at random to reply in this thread]
tell whether or not we should bail out).
Ideally we don't want to have any locks i
d fxp, bge and igb drivers in my tcp_workqueue
branch to test these concepts. Not all of it is committed or fully up to date.
--
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"
t
[1] for an example.
Does anyone know if there is a generic mechanism, or each driver
reimplements its own way ?
We desperately need a saner ifnet/driver interface. I think andre@
had some previous work in this area (and additional plans as well?).
Yes. I have received a grant from the FF to l
Not storing it on the stack?
--
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"
On 12.07.2013 12:56, Fabian Keil wrote:
Andre Oppermann wrote:
On 10.07.2013 15:18, Fabian Keil wrote:
Andre Oppermann wrote:
We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few
imb
grr .. missing attachment :-(
Thanks, applied your patch in r253214.
--
Andre
Index: /usr/src/sys/crypto/siphash/siphash.c
===
--- /usr/src/sys/crypto/siphash/siphash.c (revision 253210)
+++ /usr/src/sys/crypto/siphash
On 10.07.2013 15:18, Fabian Keil wrote:
Andre Oppermann wrote:
We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.
This patch updates and improves SYN cookies mainly
he place for
every possible ancient version of FreeBSD. This probably should
be cleaned up (and upstreamed) as well.
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscri
here for testing:
http://people.freebsd.org/~andre/syncookie-20130708.diff
Please enable TCP logdebug to see connection status reporting by the
changes.
Detailed discussion:
The purpose of SYN cookies is to encode all necessary session state
in the 32 bits of our initial sequence number to
On 19.06.2013 11:34, Ian FREISLICH wrote:
Andre Oppermann wrote:
On 19.06.2013 11:10, Ian FREISLICH wrote:
Hi
I'm seeing this panic quite regularly now. Most recent sighting on r251858.
This panic message is not very informative and very hard to extract any
meaningful hints. Do you h
On 19.06.2013 11:10, Ian FREISLICH wrote:
Hi
I'm seeing this panic quite regularly now. Most recent sighting on r251858.
This panic message is not very informative and very hard to extract any
meaningful hints. Do you have a core dump and matching debug kernel?
--
Andre
cpuid = 1
On 31.05.2013 12:17, Florent Peterschmitt wrote:
Le 31/05/2013 12:13, Andre Oppermann a écrit :
Any ideas how to fix this?
# make -j8 buildworld
--- buildworld ---
make: illegal option -- J
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
[-d flags] [-E variable] [-f
] [target ...]
*** [buildworld] Error code 2
make: stopped in /u/svn/commit/head4
1 error
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-uns
investigating
the root cause for the problem.
--
Andre
Index: sys/netinet/tcp_subr.c
===
--- sys/netinet/tcp_subr.c (revision 250330)
+++ sys/netinet/tcp_subr.c (working copy)
@@ -255,7 +255,7 @@
#define
rn Intel Core i[3-7] and AMD64
may actually improve with these changes. Unless more recent micro-archs
have been shown to exhibit the same regression we can't claim this change
was bad (other than for Pentium4).
--
Andre
ministat -s 242401.forwarding 242402.forwarding
x 242401.forwarding
pular
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 "freeb
On 15.04.2013 05:32, Julian Elischer wrote:
On 4/11/13 5:18 PM, Andre Oppermann wrote:
Excuse me for being slightly spammy but I've received feedback that we
haven't spread this information widely enough outside the inner circles
and interested people missed the announcement.
EuroB
thing should
happen via sorta published API's the other firewall packages use as well.
Most important pfil hooks. The hardest part probably is to get the locking
right.
Please run changes to src/sys/net* through glebius@ and me (andre@) first
before committing. In most, if not all ca
Excuse me for being slightly spammy but I've received feedback that we
haven't spread this information widely enough outside the inner circles
and interested people missed the announcement.
EuroBSDcon 2013: September 28-29 in Malta
=
EuroBSDcon is the Euro
one just cribbed the code from the old one), I think
the same problem would exist for the old one. As such, I don't believe
this is a regression.
Maybe we can talk Peter Holm into periodically running his file system
stress test suite against NFS to
On 16.03.2013 01:44, Peter Wemm wrote:
On Fri, Mar 15, 2013 at 2:03 PM, John Baldwin wrote:
On Friday, March 15, 2013 11:24:32 am Andre Oppermann wrote:
On 15.03.2013 14:46, John Baldwin wrote:
On Friday, March 15, 2013 9:40:56 am Andre Oppermann wrote:
Hi Rick, all,
is there a plan to
On 15.03.2013 14:46, John Baldwin wrote:
On Friday, March 15, 2013 9:40:56 am Andre Oppermann wrote:
Hi Rick, all,
is there a plan to decide for one NFS implementation for FreeBSD 10.0,
or to keep both around indefinately?
I'm talking about:
oldNFS in sys/{nfs, nfsclient, nfss
gie I could SSH into the box again, too.
The total wedge of all interfaces certainly shouldn't happen. This
smells like blocking on a lock on a socket_upcall() thereby wedging
tcp_input. I don't know the lockd code so maybe Rick knows how this
could happen.
--
Andre
The issue went aw
r NFS standards and seems to have proven itself in
some quite heavy traffic environments.
Is there any reason to keep oldNFS around other than nostalgic?
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
On 08.03.2013 10:16, Konstantin Belousov wrote:
On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote:
pager_map: is used for pager IO to a storage media (disk). Not
pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256).
>
It is more versatile. The space is used for pb
On 01.02.2013 18:09, Alan Cox wrote:
On 02/01/2013 07:25, Andre Oppermann wrote:
Rebase auto-sizing of limits on the available KVM/kmem_map instead of
physical
memory. Depending on the kernel and architecture configuration these
two can
be very different.
Comments and reviews
d moves it into the modern world order:
http://people.freebsd.org/~andre/kernel_init_mem-20130201.diff
The changes in particular are:
Move large parts of vm/vm_init.c to SYSINIT()s and de-magic old-style
kernel vm initialization.
Move vm_ksubmap_init(), bufinit() and vm_pager_bufferi
On 31.01.2013 23:25, Ian Lepore wrote:
On Thu, 2013-01-31 at 18:13 +0100, Andre Oppermann wrote:
On 28.01.2013 20:20, Alan Cox wrote:
On 01/28/2013 08:22, Ian Lepore wrote:
On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote:
On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore wrote:
I ran into a
ade on those other architectures
year ago.
Ian,
The patch below should do the trick. Can you please test?
If you have any questions about any of the definitions, feel free to
e-mail me.
Alan
P.S. When I get a little more free time, I intend to get in touch with
Andre to address the appar
doesn't have a name during loader stage. The kernel
finds the interface to use based on the MAC address. You should
set boot.netif.hwaddr as well in the kernel environment.
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.f
nization issues. I haven't
looked how the maps are managed internally. Maybe there is a natural hook
to attach such a mechanism and to allow the sub-maps to be larger in kVM
space than physical memory.
Maybe ZFS then can have its own sub-map fo
trees to better describe the
hierarchy of the maps.
Why are separate kmem submaps being used? Is it to limit memory usage of
certain subsystems? Are those limits actually enforced?
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.free
On 27.11.2012 20:16, Alan Cox wrote:
On 11/27/2012 12:43, Andre Oppermann wrote:
On 27.11.2012 19:27, Alan Cox wrote:
On 11/27/2012 12:08, Andre Oppermann wrote:
On 27.11.2012 17:42, Alan Cox wrote:
On 11/27/2012 09:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100
On 27.11.2012 19:27, Alan Cox wrote:
On 11/27/2012 12:08, Andre Oppermann wrote:
On 27.11.2012 17:42, Alan Cox wrote:
On 11/27/2012 09:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov
On 27.11.2012 17:42, Alan Cox wrote:
On 11/27/2012 09:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64
#0
On 27.11.2012 16:51, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 04:38:12PM +0100, Andre Oppermann wrote:
On 27.11.2012 16:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17
On 27.11.2012 16:40, Andriy Gapon wrote:
on 27/11/2012 17:38 Andre Oppermann said the following:
Clang doing a manual kernel build of my work tree with "make -j8 kernel".
This sounds like a "process" that may have triggered the problem.
But is it the process that mad
On 27.11.2012 16:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64
#0 doadump (textdump=-2014022336) at pcpu.h
On 27.11.2012 16:05, Attilio Rao wrote:
On Tue, Nov 27, 2012 at 11:26 AM, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64
#0 doadump (textdump=-2014022336) at pcpu.h:229
#1
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64
#0 doadump (textdump=-2014022336) at pcpu.h:229
#1 0x8033e2d2 in db_fncall (dummy1=,
dummy2=,
dummy3=, dummy4=)
at /usr/src/head/sys/ddb/db_
) Intel i82598 and i82599 10GigE
mxge(4) Myricom Myri10G
qlxgb(4) QLogic 3200 and 8200 10GigE
sfxge(4) Solarflare
Many thanks for your support!
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
On 14.11.2012 03:10, Alfred Perlstein wrote:
Andre, do you think the variable "realmem" could be exported as something like
kmemsize or something?
Or maybe a function call to subr_param.c?
The reason I ask is that I would like to scale things like number of default
sysv sem
ue as I proposed in a recent email to Luigi? That way we
don't need special cases or features or even a normal server under
DDoS wouldn't go down.
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
On 06.11.2012 12:30, Luigi Rizzo wrote:
On Tue, Nov 06, 2012 at 11:23:34AM +0100, Andre Oppermann wrote:
...
Hi Luigi,
do you agree on polling having outlived its usefulness in the light
of interrupt moderating NIC's and SMP complications/disadvantages?
yes, we should let it rest in
On 06.11.2012 11:27, Poul-Henning Kamp wrote:
In message <5098e526.6070...@freebsd.org>, Andre Oppermann writes:
Hi Luigi,
do you agree on polling having outlived its usefulness in the light
of interrupt moderating NIC's and SMP complications/disadvantages?
Can I jus
ieu of upcoming superior alternatives (netmap
enabled features). It was a great feature in the past but is beyond
retirement and should live a peaceful live in the attic.
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/ma
On 05.11.2012 02:39, Manfred Antar wrote:
At 01:57 PM 11/4/2012, you wrote:
On 04.11.2012 21:15, Andreas Tobler wrote:
On 04.11.12 14:57, Andre Oppermann wrote:
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar
On 04.11.2012 21:15, Andreas Tobler wrote:
On 04.11.12 14:57, Andre Oppermann wrote:
On 04.11.2012 13:11, Kim Culhan wrote:
On Sun, November 4, 2012 6:21 am, Dimitry Andric wrote:
On 2012-11-04 02:13, Manfred Antar wrote:
At 03:29 PM 11/3/2012, Adrian Chadd wrote:
After the commit, there
On 22.10.2012 15:28, John Baldwin wrote:
On Sunday, October 21, 2012 7:11:10 am Andre Oppermann wrote:
What's keeping kernel modules from building in parallel with
"make -j8"?
They don't for you? They do for me either via 'make buildkernel'
or the old method.
later
the following files were changed:
sys/netinet/tcp_input.c
sys/netinet/tcp_timer.c
sys/netinet/tcp_var.h
Building a kernel from these new files is when the problem starts.
So, your problems seem to have been introduced by this commit by Andre:
http://svn.freebsd.org/changeset/base/2422
ys/netinet/tcp_var.h
Building a kernel from these new files is when the problem starts.
Can you please provide one or more tcpdump from a failing kernel?
Also please enable sysctl net.inet.tcp.logdebug=1 and capture LOG_DEBUG
output from syslogd. That may give some important informatio
MAXUSERS
This is very round-about. Why don't you simply write 384 per GB in
there directly?
Thinking of it these "magic" whatever-per-GB value definitions
should be next to each other in param.h or some other suitable
place.
--
Andre
The ZERO_COPY_SOCKETS kernel option has been removed from HEAD
today. Please see the explanation in the attached commit message.
--
Andre
--- Begin Message ---
Author: andre
Date: Tue Oct 23 16:33:43 2012
New Revision: 241955
URL: http://svn.freebsd.org/changeset/base/241955
Log:
Note the
yn_buckets=65536
net.inet.ip.fw.dyn_ack_lifetime=120
net.inet.ip.fw.dyn_syn_lifetime=10
net.inet.tcp.nolocaltimewait=1
security.bsd.hardlink_check_uid=1
security.bsd.hardlink_check_gid=1
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
What's keeping kernel modules from building in parallel with
"make -j8"?
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "free
s
some analysis because there are some dependencies and memory
requirements.
--
Andre
Adrian
On 3 October 2012 11:45, wrote:
Hi everyone.
Actually 65k sockets is incredibly easy to reach.
I manage some servers for a very large website, it currently has several
http servers clustered to handle
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 20.04.2012 08:35, Luigi Rizzo wrote:
On Fri, Apr 20, 2012 at 12:37:21AM +0200, Andre Oppermann wrote:
On 20.04.2012 00:03, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
The allocation happens while the code has
On 20.04.2012 10:26, Alexander V. Chernikov wrote:
On 20.04.2012 01:12, Andre Oppermann wrote:
On 19.04.2012 22:34, K. Macy wrote:
If the number of peers is bounded then you can use the flowtable. Max
PPS is much higher bypassing routing lookup. However, it doesn't scale
>
On 20.04.2012 00:03, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
The allocation happens while the code has already an exclusive
lock on so->snd_buf so a pool of fresh buffers could be attached
there.
Ah, there
p.
Yes, but the lookup requires a lock? Or is every entry replicated
to every CPU? So a number of concurrent CPU's sending to the same
UDP destination would content on that lock?
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lis
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
owtable isn't
lockless in itself, is it?
--
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"
hanges. However changes
are seldom to essentially never with a single default route.
After that the ARP table will gets same treatment and the low stack
lock contention points should be gone for good.
--
Andre
___
freebsd-current@freebsd.org mailing list
On 11.04.2012 13:00, Luigi Rizzo wrote:
On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote:
On 11.04.2012 01:32, Luigi Rizzo wrote:
On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote:
CPU cache?
Cx states?
powerd?
powerd is disabled, and i am going down to C1 at most
scheduling decision...)
Things going through loopback go through a NETISR and may
end up queued to avoid LOR situations. In addition per-cpu
queues with hash-distribution for affinity may cause your
packet to be processed by a different core. Hence the additional
delay
O_NONBLOCK and select/poll
on the socket.
Do you have any references how other OSes behave, in particular
Linux?
I've added bde@ as our resident standards compliance expert.
Hopefully he can give us some more insight on this issue.
--
Andre
___
in
having a parallel software implementation. And then you run into
the mbuf chain copying issue further down the layer. The win won't
be much.
--
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"
On 08.12.2011 14:11, Lawrence Stewart wrote:
On 12/08/11 05:08, Luigi Rizzo wrote:
On Wed, Dec 07, 2011 at 11:59:43AM +0100, Andre Oppermann wrote:
On 06.12.2011 22:06, Luigi Rizzo wrote:
...
Even in my experiments there is a lot of instability in the results.
I don't know exactly wher
ects high-speed single sessions throughput has crept in. That's
difficult to debug though.
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "
ell
+ /etc/rc.d/*.sh | /usr/local/etc/rc.d/*.sh) # run in current shell
set $_arg; . $_file
;;
*[~#]|*.OLD|*.bak|*.orig|*,v) # scratch file; skip
Or even use *.sh)
Thanks,
-Andre
> all run in subshells. You could answer this for yourself by looking i
out the FreeBSD source tree. They also may conflict with newer
versions one wants to have on a development machine (python3, perl6, ...).
Is there a way to cut this down a bit and just have a svn client with only
the necessary stuff?
--
Andre
___
freebsd
scalability reason to give up on
traditional operating system organizations just yet.
http://pdos.csail.mit.edu/papers/linux:osdi10.pdf
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
ill, if I were to change
any topologies now I would definitely go with the chained-hash /
small-linear-array / chain / small-linear-array / chain mechanic. It
seems to be the clear winner.
Without first studying the accesses pattern and applying it to
the various d
On 30.09.2010 19:51, Ivan Voras wrote:
On 09/30/10 18:37, Andre Oppermann wrote:
Both the vmmap and page table make use of splay trees to manage the
entries and to speed up lookups compared to long to traverse linked
lists or more memory expensive hash tables. Some structures though
do have
On 30.09.2010 23:44, Andre Oppermann wrote:
On 30.09.2010 20:04, Roman Divacky wrote:
On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote:
On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote:
On 30.09.2010 19:24, Roman Divacky wrote:
are you aware of Summer of Code 2008
On 30.09.2010 20:04, Roman Divacky wrote:
On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote:
On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote:
On 30.09.2010 19:24, Roman Divacky wrote:
are you aware of Summer of Code 2008 project by Mayur Shardul?
I remember that
On 30.09.2010 20:38, Alfred Perlstein wrote:
Andre,
Your observations on the effectiveness of the splay tree
mirror the concerns I have with it when I read about it.
I have always wondered though if the splay-tree algorithm
was modified to only perform rotations when a lookup required
more
On 30.09.2010 20:01, Alan Cox wrote:
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann wrote:
On 30.09.2010 18:37, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly) in
the FreeBSD VM
On 30.09.2010 19:24, Roman Divacky wrote:
are you aware of Summer of Code 2008 project by Mayur Shardul?
I remember that there was this project but I never saw any numbers
or other outcome of it. Haven't checked p4 to look at the code
though.
--
Andre
quoting: http://www.freebs
On 30.09.2010 19:15, Matthew Fleming wrote:
On Thu, Sep 30, 2010 at 9:37 AM, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly) in
the FreeBSD VM system suspecting an interesting journey
On 30.09.2010 18:37, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly) in
the FreeBSD VM system suspecting an interesting journey.
Correcting myself regarding the history: The splay
;ve hacked up a crude and somewhat
mechanical patch to convert the vmmap and page VM structures to
use RB trees, the vmmap part is not stable yet. The page part
seems to work fine though.
This is what I've hacked together so far:
http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.di
On 15.09.2010 17:19, Bjoern A. Zeeb wrote:
On Mon, 13 Sep 2010, Andre Oppermann wrote:
Hey,
When a TCP connection via loopback back to localhost is made the whole
send, segmentation and receive path (with larger packets though) is still
executed. This has some considerable overhead.
To short
On 14.09.2010 18:08, Fabien Thomas wrote:
On 14 sept. 2010, at 17:41, Andre Oppermann wrote:
On 14.09.2010 11:18, Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about "my loopback is slow vs linux"
To have the best of both world what about a socket option
aw something like that while glancing over the Linux code some
time ago. Couldn't make much sense out of the code snipped because
their TCP code split into a myriad of small functions and thus hard
to follow in the beginning. Not the ours is much easier on a beginner.
--
Andre
___
Good point. You can't at the moment but it certainly makes a lot
of sense. Let me see what I can come up with.
--
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"
quot;.
A sysctl to that effect is already in the patch.
--
Andre
Fabien
On 13 sept. 2010, at 13:33, Andre Oppermann wrote:
When a TCP connection via loopback back to localhost is made the whole
send, segmentation and receive path (with larger packets though) is still
executed. This has some c
On 13.09.2010 14:45, Poul-Henning Kamp wrote:
In message<4c8e0c1e.2020...@networx.ch>, Andre Oppermann writes:
To short-circuit the send and receive sockets on localhost TCP connections
I've made a proof-of-concept patch that directly places the data in the
other side's socke
properly
defuse the sockets in all situations.
Testers and feedback wanted:
http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff
--
Andre
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To u
On 02.09.2010 00:11, ben wilber wrote:
On Sep 1, 2010, at 8:57 AM, Andre Oppermann wrote:
On 01.09.2010 01:13, ben wilber wrote:
Hi,
I just upgraded from r210042 to r212073 and keep getting the panic
introduced in r211317:
panic: tcp_output: len<= tso_segsz
Please try the attached pa
On 02.09.2010 00:11, ben wilber wrote:
On Sep 1, 2010, at 8:57 AM, Andre Oppermann wrote:
On 01.09.2010 01:13, ben wilber wrote:
Hi,
I just upgraded from r210042 to r212073 and keep getting the panic
introduced in r211317:
panic: tcp_output: len<= tso_segsz
Please try the attached pa
respond again later
in the evening.
--
Andre
db:0:kdb.enter.default> bt
Tracing pid 12 tid 100063 td 0xff001881b000
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x1c8
tcp_output() at tcp_output+0x1445
tcp_do_segment() at tcp_do_segment+0x252d
tcp_input() at tcp_input+0x1044
ip_input()
makes things harder to read.
- cross-post, it's almost always not necessary.
Regards,
Andy
> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
___
[EMAIL PROTECTED] mailing li
g with pathmtu discovery
which I thought to reside in ip6_getpmtu().
Thank you for catching the bug!
--
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
1 - 100 of 289 matches
Mail list logo
