On Fri, 2023-04-21 at 13:46 +0000, Benjamin Beichler wrote: > Move the former *_add function with its implicit initialization into a > separate function, when the user explicitly wants to init with the first > added value, although this creates issues, when 0 is a expected value for > the internal value. > > Add a separate init function with value parameter to allow init with > distinct value, which was formerly done by the implicit init of old > *_add function. > Sure, this is what you said :-) I still don't really think it's feasible. First, this breaks all the users, because if you have e.g. virtio's DECLARE_EWMA(pkt_len, 0, 64) then it will take a long time to get away from 0. So then we could say we'll just fix them, but what value actually makes sense to init with? You don't necessarily know, right? Initially biasing towards the first value makes a lot more sense than initially biasing towards zero, no? And then if you want to achieve that, now you have to either use _add_or_init(), which is probably what people will do, but that continues having the problem ... I don't really see how this is a net improvement - we'd still have to fix the individual users with it, e.g. maybe the mesh case that started this investigation could bias towards success (init with 100) and then use _add() rather than _add_or_init(), but then again we're back to having to make individual choices with the users. I don't really see how that's better than fixing it for real with the existing behaviour of biasing towards the first value? johannes
