Hubert Feyrer <hubert%feyrer.de@localhost> writes: > On Fri, 11 Nov 2016, Michael van Elst wrote: >> Since we don't have floating point the computation should be done in >> fixed point arithmetic, e.g. >> >> r_avgcount = (A * r_avgcount + B * INT2FIX(r_mcount)) / (A + B); >> >> With the current A=B=1 you get alpha=0.5, but other values are thinkable >> to make the balancer decide on the short term thread count or an even >> longer term moving average. >> >> Using one fractional bit for INT2FIX by multiplying by two might not >> be enough. > > I see a lot of ground for more research here, determining right amount > of bits and A and B. To sum up our options at this point: I see two separate issues. One is the mixing ratio of the old average and the new value. The other is how values are scaled to have a representation with enough precision. The patch to multiply by 4, but still adding and dividing by 2, seems to me to have the average count be 4* the true value, and provide 2 bits of fraction. As long as counts are compared and not used in an absolute sense, I don't see any problems with that approach. > a) leave the situation as-is and wait for research to get a perfect formula > b) commit the patch we have and wait for the research to be done > > Given that the existing patch in PR kern/43561 and PR kern/51615 does > improve the current situation, I'd vote for option "b". I concur with b.
Attachment:
signature.asc
Description: PGP signature