[sugar] Memory allocation indicators

[Benjamin M. Schwartz]

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

Kent Loobey wrote:
| On Wednesday 12 March 2008 10:51:15 pm Benjamin M. Schwartz wrote:
|>  The
|> question is: do users need  to know how memory is being used, and if so,
|> what sort of indicator is appropriate?
|
| As a rule of thumb you shouldn't tell a user anything that you will not let
| them do something about.  So in this case unless you are going to list the
| memory demand of all of the activities they could optionally start next
there
| is no point in telling them how much memory they are allready using.

Users would quickly get a feel for how much "ring space" each activity
takes, since the amount of space is shown at runtime.  If launching failed
with a not-enough-memory error, people would get the picture very quickly.

|
| I do think indicating how many activities they have running of the total
| number they can run is VERY useful.

The total number of Browse instances you can run is about 3.  The total
number of Terminal instances you can run is probably 20 or more.

|
|> Also, it would be easy for Rainbow to enforce a pre-set hard limit on
|> memory usage for each Activity separately.
|
| Does Python support activity segment overlays?

I was specifically referring to per-user memory limits.  Since Rainbow
creates a new, independent user for each Activity instance, all the
standard Linux per-user accounting can easily be activated.  These
standard kernel-level tools include limits on amount of memory used,
number of processes, amount of disk space, number of inodes, minimum
process priority level, etc.

|> I think that this is very
|> interesting, since it would allow us to ensure that OOM never happens, by
|> only launching an activity if all activities could still max out their
|> quota afterwards.  However, this reduces the functionality of the system,
|> by limiting the number of running activities to the worst-case scenario.
|
| Hmm, one could divide the total available memory into pages (say 16KB
each).
| Then each activity could specify the number of pages it needs to run.  You
| could then use that number to inform decisions.

"Paging" is handled at the kernel level.  Yes, Activities could indicate
ahead of time how much memory they require.  That is precisely the
proposal I was discussing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH2UyQUJT6e6HFtqQRAq7TAJ9ll6Os3Z1BDq9jzjgW3/oWRXQT4QCbBdWz
+qhkyNFm2pA+xyFAMTg/b+0=
=nPjL
-----END PGP SIGNATURE-----