bird-1.5.0-1.x86_64 crasches quite often on reconfiguration including renaming BGP protocols due to bad set of CFLAGS passed on compilation

[Bartek Radwan]

On 30.03.2016 09:26, Bartek Radwan wrote:
> On 28.03.2016 12:21, Tomasz Pala wrote:

> I'll post the group when i find out more.
> I'll try to remove -fwrapv.

Loadavg is still varied with:

- binary 1.5.0 from upstream (ftp://bird.network.cz/pub/bird/redhatbird-
1.5.0-1.x86_64.rpm)

- 1.5.0-2 (PLD cflags with addition of -fno-strict-aliasing 
-fno-strict-overflow)

- 1.5.0-3 (just PLD cflags with cherry-picked commits resolving primary 
segfault issue )

- vanilla 1.5.0 (ftp://bird.network.cz/pub/bird/bird-1.5.0.tar.gz) 
compiled with upstream cflags)

I've tried above aproaches with gcc 4.9.2 (current PLD's 1.5.0-1 is 
compiled with gcc 4.9.2) and with gcc-5.3.0-2 as well - gcc still varies.

Next thing i've found is that level of loadavg peaks is higly realted to 
scan time bird's kernel protocol. We'were using quite small value of 
10s, after increasing to 300s loadavg looks OK.

Since bird receives async netlink notifications about new alien routes 
i'm just wondering if 10 seconds scan time was not too small (however 
default is 20s, and with 20s peaks are still observable).

Next thing i've checkd was comparison of perf samples with perf sample 
for for some of bird versions with varying loadavg during high and low 
loadavg periods:

http://www.sq9mev.info/unstable_near1_near0_perf.diff.txt

I cant recognize any big difference.


Then I've compared perf data with PLD 1.5.0-1 (stable loadavg) with 
1.5.0-1 provided by upstream:
http://www.sq9mev.info/stable_unstable.diff.txt

First thing that i've noticed thet there's noticable if_find_by_index 
(+20%) amount of if_find_by_index ocurrances in "unstable" perf data, 
while it's not in "stable" perf data.

I've got not enough knowledge to investigate any further, but seems to 
me that the "peaks" may be just normal with lower kernel sync time values.

I'll go with this to bird list again.

Tomasz or anybody else - do you have any hints or ideas?
What about increasing kernel scan time to higher values?


-- 
Regards
Bartek