75183 - Need per-session cache eviction policy for chrome sessions

Status: RESOLVED FIXED

(Core :: Networking: Cache, defect)

Description

[selmer (gone)]

Need to implement a per-session cache eviction policy so the chrome cache
session can have its own portion of the memory cache.  See also bug 71580 and
bug 71581.

Comment 1

[gordon]

I've already got a bug (and proposed patch) for this.  I'm just waiting for 
reviews.


*** This bug has been marked as a duplicate of 75171 ***

Comment 2

[Darin Fisher]

gordon: this is not a dupe of bug 75171.  selmer opened this bug b/c we need
to be able to alter the eviction *policy* for different cache clients.  right
now all entries in the memory cache are weighted equally.  but, we'd like to 
be able to make chrome images more sticky.  one way to do this would be to use
the rubber-band approach to dividing up the available space amongst cache
clients.  we could perhaps think of other methods as well.

Comment 3

[gordon]

Why not just mark the chrome entries as "never expires".  Or, if it is desired to 
keep all of them in memory until the chrome changes, they could be stored as a 
set in a single cache object (nsSupportsArray of chrome images for example) and a 
single descriptor to that entry could be held open.  But, if eviction isn't 
desired, perhaps they shouldn't be stored in the cache at all.

It's not clear to me how bug 71581 is related to this one.

What is the desired eviction policy for chrome images?

Comment 4

[Darin Fisher]

gordon: i didn't realize that our eviction policy considered the expiration
time.  i thought it was only LRU.  what is our current eviction policy?

Comment 5

[gordon]

The cache doesn't consider the expiration time, but clients can.  It wouldn't be 
difficult for the cache to factor the expiration time in somehow (there's another 
bug open to investigate that - bug 72511).  I need to understand the problem 
we're trying to solve here, in order to know how to fix it.  From the original 
description of this bug, I suspect we're trying to fix a symptom rather than 
underlying illness.

Comment 6

[selmer (gone)]

At last week's catfood meeting we decided to have 2 LRU lists.  One for "never
expire" content and another for everything else.  Since all chrome is "never
expire", this effectively separates chrome content from all other content.

In addition, we agreed to evict from the general LRU list before evicting from
the never expire LRU list.

Any progress on this?

Comment 7

[gordon]

Not yet.  I'm working on finishing up 0.9 bugs first.

Comment 8

[gordon]

When I change the eviction policy for the memory cache, it also needs to account 
for changes in the size of metadata.

Comment 9

[gordon]

Attachment: 2-level eviction for mem cache

Comment 10

[gordon]

This patch doesn't take into account changes in the size of metadata, and the 
threshold isn't settable via preferences yet.

Comment 11

[Darin Fisher]

your patch looks good to me, r/sr=darin... though i recall we were also
discussing ordering on the basis of whether or not an expiration time was given.
why was a size crition chosen over this?

Comment 12

[gordon]

I forgot which criteria we settled on (I should have reread the bug).  I'll 
change it to expiration time, and resubmit the patch.

Comment 13

[selmer (gone)]

In a later meeting, we said that both expiration and size were important.  Is it
still possible to combine them?

Comment 14

[gordon]

Sure, easy.  Is 40k a good first guess for size?  We will keep all objects < 40k, 
with no expiration in a preferred queue.  Let's try that for awhile and tune it 
as necessary.

Comment 15

[selmer (gone)]

Hmmm.  What I meant was preferred queue contains non-expiring stuff and is last
evicted.  The other main queue contains everything else and is evicted in a
f(size ,LRU) algorithm.

Comment 16

[gordon]

Attachment: factor size and expiration time into eviction policy

Comment 17

[gordon]

Steve, I only remember trying to find the best way to differentiate chrome 
objects (which we want in the preferred queue) from other objects.  We thought 
that differentiating them based on their size and expiration dates would be 
feasible.  I don't remember the discussion as being about cache tuning in 
general.

I'm open to any suggestion you might have for a f(size, expiration) function.

Comment 18

[selmer (gone)]

Sorry, perhaps I'm munging things because I'm not versed in this code.

I recall that we said using "never expires" was sufficient to determine that it
was code.  This was independent of the size of the item (although we believed
all these items were less than 50k.)

Separately, it was said that we should evict the biggest thing possible because
it's more efficient to bring back one big thing over the net than it is to bring
back a slew of little things.  Hence, I thought we agreed the non-chrome queue
should make some reasonable attempt to get the largest item to evict.

My suggestion for f() would be something like the clock algorithm.  Scan the
next N items and evict the largest of them.  Then advance your pointer to the
next item.  If you hit the end of the list, wrap around to the beginning. (The
value of N is tuned based on the cost of the evaluation function.) 

Comment 19

[gordon]

Attachment: fix bug in last patch to actually use new EvictionList() method.

Comment 20

[Darin Fisher]

sr=darin

steve: gordon's patch makes it so that we'll prefer not to evict stuff that
doesn't have an expiration time provided it is not too large.  IMO this is
the right thing to do as it prevents one large never-expires item from blowing
away many of our other (smaller) has-expiration items.

Comment 21

[gordon]

I'm marking this bug fixed, because it pertains to a separate eviction policy for 
chrome.  Steve, the issue concerning general performance tuning of the memory 
cache can be followed in bug 72511.

I don't quite follow the clock algorthm as you describe, but I agree with the 
part about examining N entries and evicting the largest.  I'll talk with you in 
person to get that straightened out.