#2278 BLOC Future : Memory pressure

[Zarro Boogs per Child]

#2278: Memory pressure
---------------------------+------------------------------------------------
   Reporter:  cjb          |       Owner:  cjb           
       Type:  defect       |      Status:  new           
   Priority:  blocker      |   Milestone:  Future Release
  Component:  performance  |     Version:                
 Resolution:               |    Keywords:                
Next_action:  communicate  |    Verified:  0             
  Blockedby:               |    Blocking:                
---------------------------+------------------------------------------------

Comment(by thomaswamm):

 Replying to [comment:21 cjb]:
 > Replying to [comment:20 thomaswamm]:
 > > can memory paging/swapping be switched off?
 >
 > It already is.  As you'll see when you run top, we don't use swap.

 Okay, I can't claim to know what I'm talking about, but I'll talk anyway.
 So swap is switched off, in the sense that dirty RAM pages are not written
 out to NAND flash for later retrieval.  But read-only code is paged in,
 and some RAM pages are re-used over and over again if I correctly
 understand gnu (above). The re-using is costly in time and joules, but is
 allowed.

 Can RAM page re-use be switched off, so code is only ever read into RAM
 once?  RAM pages would only be released for re-use when a task exits.

 Is there any way for a program to be allocated some recommended amount of
 RAM, or be prohibited from loading if the needed RAM is not available?

 Could a RAM requirement be specified in the '''activity.info''' file
 included with each activity bundle?  For example,

 {{{
     RAM_request = 50MB
 }}}

 Then Sugar could decide, in consultation with the kernel, if there is
 adequate RAM to proceed with activity launch.

 The general idea I am pushing is strict pre-planned RAM budgeting, in
 contrast to RAM time-sharing which gives non-deterministic performance.  I
 don't know if XO Linux can do RAM budgeting. But are there not some real-
 time versions of Linux where predictable performance requirements preclude
 RAM time-sharing?  What can be learned from those?

 Probably you guys have already been over this a hundred times.  But the
 bug remains.  '''Improving XO software to use RAM more efficiently is not
 going to stop users from hitting the OOM wall if they can't see where it
 is.'''  I want to be able to get a message from my XO that says, "Sorry,
 not enough RAM to launch <activity>; please exit some other activities
 then try again."

-- 
Ticket URL: <http://dev.laptop.org/ticket/2278#comment:22>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system