I'd like to bring the attention back to this topic: Mark, could you reconsider removing the -2 here?
https://review.openstack.org/#/c/93889/ Your reason was: """Until the upstream blueprint (https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode ) merges in Oslo it does not make sense to track this in Neutron. """ Given the new deadlines for the specs, I believe there is no reason to finish the oslo side in a rush, but it looks like it's going to be available during this cycle. I believe it's something good which we may have available during the juno cycle, as it's a very serious performance penalty. Best regards, Miguel Ángel. ----- Original Message ----- > > > On 03/24/2014 07:23 PM, Yuriy Taraday wrote: > > On Mon, Mar 24, 2014 at 9:51 PM, Carl Baldwin <c...@ecbaldwin.net > > <mailto:c...@ecbaldwin.net>> wrote: > > > > Don't discard the first number so quickly. > > > > For example, say we use a timeout mechanism for the daemon running > > inside namespaces to avoid using too much memory with a daemon in > > every namespace. That means we'll pay the startup cost repeatedly but > > in a way that amortizes it down. > > > > Even if it is really a one time cost, then if you collect enough > > samples then the outlier won't have much affect on the mean anyway. > > > > > > It actually affects all numbers but mean (e.g. deviation is gross). > > > Carl is right, I thought of it later in the evening, when the timeout > mechanism is in place we must consider the number. > > > > > I'd say keep it in there. > > +1 I agree. > > > > > Carl > > > > On Mon, Mar 24, 2014 at 2:04 AM, Miguel Angel Ajo > > <majop...@redhat.com <mailto:majop...@redhat.com>> wrote: > > > > > > > > > It's the first call starting the daemon / loading config files, > > > etc?, > > > > > > May be that first sample should be discarded from the mean for > > all processes > > > (it's an outlier value). > > > > > > I thought about cutting max from counting deviation and/or showing > > second-max value. But I don't think it matters much and there's not much > > people here who're analyzing deviation. It's pretty clear what happens > > with the longest run with this case and I think we can let it be as is. > > It's mean value that matters most here. > > Yes, I agree, but as Carl said, having timeouts in place, in a practical > environment, the mean will be shifted too. > > Timeouts are needed within namespaces, to avoid excessive memory > consumption. But it could be OK as we'd be cutting out the ip netns > delay. Or , if we find a simpler "setns" mechanism enough for our > needs, may be we don't need to care about short-timeouts in ip netns > at all... > > > Best, > Miguel Ángel. > > > > > > -- > > > > Kind regards, Yuriy. > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev