Memory lending

Registered by Sergey "Shnatsel" Davidoff on 2012-04-15

Be adaptive to the amount of RAM available on the system, not just swap opportunistically.

 = shell-side approach =

With our apps being so take-up-where-you-left, we can automatically close running apps which haven't been used for a while and are not performing background tasks when we get short of memory. This will allow us e.g. minimize apps instead of closing them and really close them only when we need that memory for something else.

This may work with non-native apps too: X session management specification provides a way to restore apps in exactly the same state in which they were closed, and most GNOME apps support that.

Finally, stuff like Firefox won't work that way, but we can let Firefox close itself right away and ship take-up-where-you-left config for it.

Also, we could automatically collect startup time statistics for each app and close apps with smaller startup times first.

It probably requires integration with WM to make auto-closing and restoring apps transparent.

 = app-side approach =

Make apps monitor tab usage and unload contents of unused tabs from memory in case of a web browser or make thumbnail caches in file browser, image viewer, etc adaptive to the size of available RAM.

Apps should be commanded to do so by a central hypervisor to avoid wasting resources on monitoring memory usage in every app.

This way we can forget about closing tabs too.
(man, this two-level multitasking really bugs me now!)

 = doesn't swap do the same thing? =

It does, but swapping to disk is slow and not always available (e.g. on netbooks) while swapping to zram is fast but zram is always limited. Such memory balancing allows a theoretically unlimited number of apps to "run" at the same time.

Besides, applications mostly work data that us already stored on disk but the OS doesn't know about that because they're stored in compressed form (e.g. images - JPEG, PNG, etc). So they can be discarded instead of writing them out to a swap partituon, but the OS is not aware of that. This system is.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
New
Series goal:
Accepted for future
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.