[Sugar-devel] Fwd: Activity startup idea

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomeu Vizoso wrote:
> The problem I see is that both the available memory in the system and
> the consumed memory by a single activity are complex to measure and
> much more to anticipate, so we probably won't get good enough
> estimations to put in the activity.info.

I agree that this is a very hard problem, unlikely to be solved, but I've
been thinking a bit about it anyway.  The problem, as you say, is
requiring authors to estimate the usage in activity.info.  What if,
instead, Sugar automatically estimated the memory usage of each activity
based on past performance?

Last year I wrote up an algorithm for predicting how much power each
Activity will use, using only measurements of the system's total power
usage.[1]  What I realized is, the math problem is the same for estimating
the memory usage of each Activity, knowing only the total memory usage.

In fact, we can probably do much better than that, since we have many
good, accurate tools for reporting memory usage, like  pmap.[2]  The deep
problem, as others have noted, is that the maximum memory usage of many
programs varies widely depending on the input data, and is therefore
extremely difficult to predict.

I think we can find a middle ground, a conservative, minimalist approach
to proactive memory management.  The policy is: Sugar should not allow*
the user to start an Activity that is unlikely to finish starting.  To
implement this, Sugar should measure the memory usage of each activity
immediately after startup, before the Activity is provided with any input
data.  This memory usage should be relatively consistent for each
activity, depending only on system parameters (like screen resolution and
architecture) and on shared libraries (mostly meaning which other
activities are open).

Here's a pseudocode snippet to indicate the simplest possible implementation:

def try_to_launch(some_activity):
	if (some_activity not in mem_usage database) or
(mem_usage_database[some_activity] < available_memory()):
		m1 = available_memory()
		launch(some_activity)
		m2 = available_memory()
		if m2 - m1 < mem_usage_database[some_activity]:
			mem_usage_database[some_activity] = m2 - m1
		return SUCCESS
	else:
		return INSUFFICIENT_MEMORY

This launcher prevents launching an activity if, in order to launch
successfully, the activity would have to use less memory on startup than
it has ever used before.

Over time, we can upgrade this algorithm to use advanced heuristics,
including knowledge of how different activities interact with regard to
memory usage.  This approach alone will never lead to the complete absence
of OOM conditions, but it should allow us to make them much less likely
without impairing the user experience.

- --Ben

[1] http://wiki.laptop.org/go/Per-Activity_Power_Usage
[2]
http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

*: At least, the launcher icons should change to indicate that they are
not recommended.  Unfortunately, they're already gray, so we'll have to
think of something else...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkm1RxMACgkQUJT6e6HFtqT5wgCeOijnNlIwen7RX3tTlB65zM1c
1k0AnR8jnSND79R3Lx+Z0dntMJ+uhAAy
=jyUy
-----END PGP SIGNATURE-----