I agree.
That sounds like a reasonable step to take.
Thanks for the analysis. (Please include it in the commit message.)
On Mon, Jul 14, 2014 at 06:06:09PM +0100, Anoob Soman wrote:
> Hi Ben,
>
> Thanks for the suggestions. I did some quick test and analysis of
> the stack usage on ovs-2.1.2 (
Hi Ben,
Thanks for the suggestions. I did some quick test and analysis of the
stack usage on ovs-2.1.2 (planning to do it on master later) and here
are some of the findings.
The list shows the stack usage (in bytes) by each of the functions. I
have collected only those functions which uses m
Hi Ben,
Sorry for the confusion, I was just an FYI that dom0 was 64bit. I also
agree that 32bit or 64bit shouldn't make any difference.
Thanks,
Anoob.
On 09/07/14 18:59, Ben Pfaff wrote:
I ran that command on my own development host rather than in the Xen
DDK. (I use i386 instead of x86-64 t
I ran that command on my own development host rather than in the Xen
DDK. (I use i386 instead of x86-64 to put some diversity into
development, since most developers use x86-64.) Rest assured that we
do all of our XenServer builds in the Xen DDK that corresponds to the
target XenServer target (an
Hi Ben,
From the objdump-sed (%esp) command I realised that you guys might be
using a XenServer DDK shipped with 6.2, which is 32bit. From Creedence
(next release) onwards dom0 is 64bit, and so are the tools.
http://xenserver.org/open-source-virtualization-download/24-product/creedence/143-xs-
I guess that the biggest effect on stack size would be the flow table
and in particular how much recursion flow processing causes. There are
a few tests that force as-deep-as-possible recursion:
AT_SETUP([ofproto-dpif - infinite resubmit])
AT_SETUP([ofproto-dpif - exponential resubmit cha
I have been running tests with 1MB stack size and ovs-vswitchd seem to
hold pretty well. I will try to do some more experiments to find out the
max depth of the stack, but I am afraid this will totally depend on the
test I am running. Any suggestion on what sort of test I should be
running ? Mo
On Tue, Jul 08, 2014 at 05:08:43PM +0100, Anoob Soman wrote:
> Since openvswitch has moved to multi-threaded model, RSS usage of
> ovs-vswitchd has increased quite significantly compared to the last
> release we used (ovs-1.4.x). Part of the problem is using mlockall
> (with MCL_CURRENT|MCL_FUTURE)
Hi,
Since openvswitch has moved to multi-threaded model, RSS usage of
ovs-vswitchd has increased quite significantly compared to the last
release we used (ovs-1.4.x). Part of the problem is using mlockall (with
MCL_CURRENT|MCL_FUTURE) on ovs-vswitchd, which causes every pthreads
stack's and h
