On 19 June 2013 15:35, cotton-ben <ben.cotton(a)alumni.rutgers.edu> wrote:
/
>> Benefits:
>> 1. L1 cache can be separately tuned - L1 maxEntries for example
> -1!
> I don't think thats a benefit actually, from the point of view of a user:
> [...]
> At the opposite site, I don't see how - as a user - I could optimally
tune a separate container. /
There is 1 place where this is important from the User's view. Users want
(and actually need) to be able to tune their expectations for their
Cache/Grid provider's L1 capability join-point. Specifically, a user can be
greatly empowered if their provider provides an API that assist the user's
preference for "where he wants to be" on the get(K) probability of
"hit@L1"
vs. get(K) probability of "readThrough@remoteContainer" distribution curve.
Indeed, IFF you separate the two storage areas you get in that kind of
need, but I think it's an unnecessary complexity. The world is
actually quite simple: you have N gigs of heap available, you can
estimate you want your LIRS strategy to target some M number of
entries.
Which entries exactly, you will never be able to make a good choice,
but LIRS (or other eviction strategies) are able to make a decision
which is easy to model.
This whole discussion is starting from the assumption that it is
important to keep the owned entries in memory; I don't think we should
blindly assume that.
If someone could explain an important reason to always favour owned
entries over *hotter* entries I'd be less skeptical, but even so that
would be a step backwards in ease of configuration as today the grid
basically self-tunes ergonomically.
Sanne