Necko/MobileCache: Difference between revisions

Necko/MobileCache (view source)

Revision as of 17:21, 10 October 2011

3,743 bytes added , 10 October 2011

no edit summary

Todesschaf

Confirmed users

96

edits

@@ Line 65: / Line 65: @@
 * Store cache using a single (mmapped?) file or small number of files
 ** simpler version of this might be to have BLOCK files for larger file sizes ([https://bugzilla.mozilla.org/show_bug.cgi?id=593198 bug 593198])
+== Questions for guidance ==
+These questions are intended to guide us in our goal of being able to turn on the disk cache (in some form) on mobile. This is not necessarily an exhaustive list, but it's a starting point so we don't necessarily go off the rails with ideas that may be more complex than we absolutely need. Bigger, better improvements to the cache as a whole can (and hopefully will!) come after mobile has anything at all.
+*What happens if we just turn on existing cache (now that all I/O is on separate thread)?
+**If this doesn’t slow down Tp, is there anything else preventing us from just turning it on and being done with the goal?
+*How much space do we want the disk cache to grow to?
+*What is it that is making us slow down Tp?
+**Writing to cache?
+***Because I/O tee is synchronous and eMMC is slow on writes?
+***Because writing blocks readers from doing their own I/O?
+****Can we move writing to its own separate thread?
+*****Would this work with the OS I/O scheduler (ie, would the OS not screw us anyway)?
+***Does mmap help?
+**Reading from cache?
+***Is that a characteristic of eMMC?
+***Are we just doing something stupid?
+****Bad access pattern?
+***Can this be solved using more block files?
+***Does mmap help?
+**Our algorithm?
+***What are the pain points (high O notation) in our read/write/search/evict ops?
+****Are any of these simple to fix resulting in a win?
+****Can we change them w/o a full rewrite?
+***Is there some modification to the eviction algorithm we can make? (LRU-SP?)
+***Searching for cache entry before hitting net?
+****How much time are we spending searching before we hit the net?
+****Is this number wildly different from on HDD/SSD?
+****If so, why?! This should be mostly in-memory work!
+*****Indicates that actual I/O is our problem, see above questions
+*Questions about certain things that may be needed to answer the above
+**Is OS-level I/O single threaded?
+***Motivated by bug 687367
+***This prevents any solution w/multiple I/O threads from working
+**What are the perf characteristics of read/write/seek on eMMC/HDD/SSD?
+***Want these characteristics in similar situations to our cache
+****R/W/S random in large file (simulate block files)
+****R/W standalone files in possibly large directories
+****Searching large directory for a file (simulate finding entry in separate file)
+**What percentage of the time do we spend doing I/O versus in-memory cache operations
+***HDD
+***SSD
+***eMMC
+***Are there any statistically significant differences in these?
+**Is there some threshold of device on which turning on the disk cache NEVER makes sense in its current form (or in the form we settle on for the first round)
+***Devices w/crappy eMMC parts
+***Devices w/crappy filesystems (samsung...)
+**Do we get notifications before being force-closed?
+***Feasable to write out cache map before force-closing so we don’t trash cache on startup?
+***If we can’t write cache map, what is easiest way to not blow away cache?
+****Journaling?
+****Flush cache map on a timer and accept some inconsistencies from later page loads?
+**What if the profile/cache is on sd card?
+***How often are we on sd card instead of internal storage?
+***Does this slow us way, way down?
+***Should we just disable in this case?
+***If we keep it enabled on sd card, what about security of cache data?
+***Can we keep cache on internal storage no matter what?
+**Have seen it’s a win on internal storage w/decent cache size (on a good fs)
+***Bug 645848
+***Will probably have to blacklist devices based on fs at runtime
+***Smaller cache does not appear to be a win? (Likely too much churn in cache)
+****Is Tp good enough for testing this? Bug 661900 indicates it isn't (Geoff Brown made some modifications to make it better)