[Top] [All Lists]

Re: [PATCH] repairing rtcache killer

To: davem@xxxxxxxxxx (David S. Miller)
Subject: Re: [PATCH] repairing rtcache killer
From: kuznet@xxxxxxxxxxxxx
Date: Thu, 7 Aug 2003 01:23:18 +0400 (MSD)
Cc: Robert.Olsson@xxxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <> from "David S. Miller" at Aug 06, 2003 12:52:24 AM
Sender: netdev-bounce@xxxxxxxxxxx

> >  > #   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.

<Prev in Thread] Current Thread [Next in Thread>