> > > # Two serious and interesting mistakes were made in the patch of
> > 2003-06-16.
> Mama mia! This patch exists in 2.4.22-preX too, so full fix
> becomes more urgent.
I exaggerated saying "serious". The emphasize is rather on "interesting". :-)
Mistake were not evident, Robert and me spent day and half to figure out
what the hell is going on. :-) It shows only at high flow rate and it is just
suboptimal thing, not a disaster.
> Alexey, given all this what would you like to do? Should I push
> your patch urgently into 2.4.x or spend some more time trying to
> solve this issue?
Hour ago I would say "yes". But this bus trip happened
to be productive. :-) Seems, I know how to do right thing.
I will code it now, and if Robert will be happy...
Robert, look, the idea is:
1. Periodically we reset elasticity2 to 2*elasticity, f.e. from
periodic gc timer.
2. We measure hits and misses with higher frequency, f.e. from
forced gc. The measurement are suppressed for some time
after each flush while cache collects new fresh entries.
if (misses > rt_hash_mask+1 && hits < misses)
elasticity2 = 0;
elasticity2 = 2*elasticity;
misses > rt_hash_mask+1 guarantees that cache is populated and probed
enough, rt_hash_mask+1 is not a random number, it corresponds
to maximal size with elasticity2 = 0.
Seems, it should work. And it is simple enough.