Ben Pfaff | 29 Jun 2012 18:28

[PATCH] ovs-vswitchd: Call mlockall() from the daemon, not the parent or monitor.

mlockall(2) says:

       Memory  locks  are not inherited by a child created via fork(2) and are
       automatically removed  (unlocked)  during  an  execve(2)  or  when  the
       process terminates.

which means that --mlockall was ineffective in combination with --detach
or --monitor or both.  Both are used in the most common production
configuration of Open vSwitch, so this means that --mlockall has never been
effective in production.

Signed-off-by: Ben Pfaff <blp@...>
---
 vswitchd/ovs-vswitchd.c |   22 +++++++++++++++-------
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/vswitchd/ovs-vswitchd.c b/vswitchd/ovs-vswitchd.c
index 8ef3b10..6062a40 100644
--- a/vswitchd/ovs-vswitchd.c
+++ b/vswitchd/ovs-vswitchd.c
 <at>  <at>  -55,6 +55,10  <at>  <at> 

 VLOG_DEFINE_THIS_MODULE(vswitchd);

+/* --mlockall: If set, locks all process memory into physical RAM, preventing
+ * the kernel from paging any of its memory to disk. */
+static bool want_mlockall;
+
 static unixctl_cb_func ovs_vswitchd_exit;

(Continue reading)

Justin Pettit | 29 Jun 2012 22:24

Re: [PATCH] ovs-vswitchd: Call mlockall() from the daemon, not the parent or monitor.

Great catch!  Thanks, Ben.

--Justin

On Jun 29, 2012, at 12:28 PM, Ben Pfaff wrote:

> mlockall(2) says:
> 
>     Memory  locks  are not inherited by a child created via fork(2) and are
>     automatically removed  (unlocked)  during  an  execve(2)  or  when  the
>     process terminates.
> 
> which means that --mlockall was ineffective in combination with --detach
> or --monitor or both.  Both are used in the most common production
> configuration of Open vSwitch, so this means that --mlockall has never been
> effective in production.
> 
> Signed-off-by: Ben Pfaff <blp@...>
> ---
> vswitchd/ovs-vswitchd.c |   22 +++++++++++++++-------
> 1 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/vswitchd/ovs
From: Nicira Support <no-reply@...>
Subject: [nicira-support] Alert: Case 606 created for New Dream Network, LLC
Date: 2012-06-29 16:27:06 GMT
(Continue reading)

Ben Pfaff | 30 Jun 2012 02:20

Re: [PATCH] ovs-vswitchd: Call mlockall() from the daemon, not the parent or monitor.

Thanks, I pushed this to master, branch-1.7, branch-1.6, and I'll 
crossport to earlier branches in a while.

On Fri, Jun 29, 2012 at 04:24:22PM -0400, Justin Pettit wrote:
> Great catch!  Thanks, Ben.
> 
> --Justin
> 
> 
> On Jun 29, 2012, at 12:28 PM, Ben Pfaff wrote:
> 
> > mlockall(2) says:
> > 
> >     Memory  locks  are not inherited by a child created via fork(2) and are
> >     automatically removed  (unlocked)  during  an  execve(2)  or  when  the
> >     process terminates.
> > 
> > which means that --mlockall was ineffective in combination with --detach
> > or --monitor or both.  Both are used in the most common production
> > configuration of Open vSwitch, so this means that --mlockall has never been
> > effective in production.
> > 
> > Signed-off-by: Ben Pfaff <blp@...>
Ethan Jackson | 30 Jun 2012 02:35

Re: [PATCH] ovs-vswitchd: Call mlockall() from the daemon, not the parent or monitor.

Thanks!

On Fri, Jun 29, 2012 at 5:20 PM, Ben Pfaff <blp@...> wrote:
> Thanks, I pushed this to master, branch-1.7, branch-1.6, and I'll
> crossport to earlier branches in a while.
>
> On Fri, Jun 29, 2012 at 04:24:22PM -0400, Justin Pettit wrote:
>> Great catch!  Thanks, Ben.
>>
>> --Justin
>>
>>
>> On Jun 29, 2012, at 12:28 PM, Ben Pfaff wrote:
>>
>> > mlockall(2) says:
>> >
>> >     Memory  locks  are not inherited by a child created via fork(2) and are
>> >     automatically removed  (unlocked)  during  an  execve(2)  or  when  the
>> >     process terminates.
>> >
>> > which means that --mlockall was ineffective in combination with --detach
>> > or --monitor or both.  Both are used in the most common production
>> > configuration of Open vSwitch, so this means that --mlockall has never been
>> > effective in production.
>> >
>> > Signed-off-by: Ben Pfaff <blp@...>
> _______________________________________________
> dev mailing list
> dev@...
> http://openvswitch.org/mailman/listinfo/dev
(Continue reading)


Gmane