Closed
Bug 846199
Opened 12 years ago
Closed 2 years ago
Add LRU logic to lmk process eviction
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: cjones, Unassigned)
References
Details
(Keywords: perf, Whiteboard: [UX-P?])
Bug 822325 will add the simplest possible LRU implementation, but we'd like to do better than that. We can fix bug 822325 independently of this since it's higher priority.
If you run b2g for a while, you'll notice that "skinny" processes tend to accumulate in the background and prevent more-recently-used less-skinny processes from staying alive. While the SMS app might use a bit more memory than the calculator, if I used the SMS app in the last 5 minutes, but last used the calculator last week, I'd rather have the calculator gunned down first under memory pressure.
We'll want to avoid considering "services" in LRU computation, since the user doesn't launch them explicitly. E.g. cost control / calendar.
We need to understand the android prior art for implementing this. I don't know offhand how LRU works with lmk, beyond the LAST_PROCESS hack.
Reporter | ||
Comment 1•12 years ago
|
||
Once we have this infrastructure in place, the next step would "frecency"-derived process priorities. I may have used the calculator 5 minutes ago and the SMS app 10 minutes ago, AND calculator may be skinnier, but if I launch SMS 100 times a day and calculator once a week, we should prefer keeping SMS alive.
Updated•2 years ago
|
Severity: normal → S3
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•