#3335 NORM Untriag: Home view activity sector size

[Zarro Boogs per Child]

#3335: Home view activity sector size
---------------------+------------------------------------------------------
  Reporter:  bert    |       Owner:  danw     
      Type:  defect  |      Status:  new      
  Priority:  normal  |   Milestone:  Untriaged
 Component:  sugar   |     Version:           
Resolution:          |    Keywords:           
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by danw):

 Replying to [comment:3 bert]:
 > Try Write, Browse, TamTam and it gets pretty full. And then launch a few
 more Browse instances.

 Jeez. Who knew TamTam was so huge.

 "a few more Browse instances" is also a known problematic case; since they
 share all their code and some of their heap, N instances of an activity
 take up much less memory than N times what 1 instance takes up. But the
 activity ring enforces a minimum size for each wedge, so you end up with,
 say, 5 Browse instances taking up half of the wedge (5 * 1/10) even though
 they're only taking 1/4 of memory (and then everything else must be
 squished accordingly).

 Rainbow "fixes" this somewhat by not letting a single process host
 multiple instances of an activity.

 > "swap out" is probably not the right term since we do not swap into
 flash, right?

 I think it's still called "swapping". (It doesn't need to swap the data
 "into" anywhere, because it's already on the flash disk.)

 Anyway, I'm trying to figure out if we can use the "Inactive" line in
 /proc/meminfo, but I can't figure out if that only includes pages that
 really can be "swapped" out (in our case, file-backed stuff), or if it
 also includes inactive pages that will turn out to be unswappable because
 we don't have swap. If the latter, then it doesn't help us.

 Alternatively, the "Referenced" lines in /proc/PID/smaps might be useful?
 Unfortunately this stuff isn't really documented in detail.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3335#comment:4>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system