Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter)

From: [email-masked] (Noel Chiappa)
Date: Wed, 30 Mar 2011 10:43:56 -0400 (EDT)

> From: "Joel M. Halpern" <[email-masked]>

    > While I like the theory you advance, I don't know how to build it in
    > practice. What size memory .. should I build in my device to meet the
    > MUST?

What you say is of course true, but at the same time, I don't think it
invalidates my basic point, that the only way to prevent cache thrashing in
an application like this is to have a 'big enough' cache?

Is there any reason not to say that, even if we don't have a number to put
in? As Dino says, this is true now, in many other places: e.g. BGP 'won't
work' without a large enough RIB to hold the entire table, but I don't
believe the size is in any document.

    > I presume there is already some data.

The simulations I mentioned were driven by very large traces of actual
traffic from several large sites. Everyone who is seriously interested in
this issue should read those papers.

    > I do not see that the document needs to spell out all of the history of
    > our problems

True, but if we agree that i) thrashing is an issue (and I think we do all
agree on that), and ii) the only fix to thrashing is a large enough cache (so
far, I hear no dissent on that), I think the document ought to say both of
those.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 30 Mar 2011 12:22:17 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > an implementation MUST have some form of cache management in place
    > that would provide suppression of cache thrasing.

Do you know of any cache management strategy which will achieve this goal
_other_ than simply having a big enough cache? (Or is the answer to that
question proprietary? :-) If not, why can't we just simply say that, and
we can drop all the "The specific management mechanisms ... work best."
stuff?

	Noel

PS: Someone pointed out "Revisiting Route Caching: The World Should Be
Flat" to me, which is a nice piece of work (although it misunderstands
LISP); it makes the observation that LRU works a lot better than LFU as a
discard selection mechanism.