[Sugar-devel] #2141 UNSP: Memory and CPU status indicator for the frame.

[Anish Mangal]

There is information in the /proc filesystem we could use to refine
the heuristics.

/proc/meminfo - How much physical memory.
/proc/loadavg - How many IOWAIT cycles.
/proc/cpuinfo - How fast is my machine. How many CPUs.

But I guess we should try out the current resource indicator on many
different types of machines, to get a good idea of how bad the current
heuristics really are.

Btw, I wouldn't say the current heuristics are 'tuned' for the xo or
any machine in particular. Here's how it works.

0 < memory free < 100
0 < cpu free < 100

  0 < mem + cpu free <= 67        => unhappy
 67 < mem + cpu free <= 133      => serious/normal
133 < mem + cpu free <= 200      => happy

On Wed, Sep 15, 2010 at 6:48 PM, David Farning <dfarning at gmail.com> wrote:
> On Wed, Sep 15, 2010 at 5:59 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>> On Wed, Sep 15, 2010 at 12:12, James Cameron <quozl at laptop.org> wrote:
>>> On Wed, Sep 15, 2010 at 10:40:06AM +0200, Tomeu Vizoso wrote:
>>>> Basically, I don't see how this could work without being tuned to very
>>>> specific systems.
>>>
>>> I've reviewed the patch [1], and I disagree with your assessment.  It
>>> would work without any tuning to specific systems.  The learner would
>>> learn that system response correlates to the face.
>>
>> As said in the ticket, in some systems regardless of the load the face
>> would be always happy or always sad. I expect users to be confused
>> about this.
>>
>> I guess the intention is that after you start Sugar, the face would be
>> happy. As the user activity consumes more resources, the face becomes
>> neutral and when there aren't enough resources to provide a good user
>> experience (things slow down or risk of OOM grows) the face becomes
>> sad.
>>
>> Now, if you try this specific patch out in systems different enough
>> from the XO, you will see that the face stays in the same state
>> regardless of the user activity. Examples of such systems are most
>> modern netbooks, which ship with a minimum of 1GB of RAM and often
>> have CPUs with 2 cores. Another example are LTSP systems. Or systems
>> with less memory than the XO but with some swap. This is because the
>> current algorithm is tuned for the base free resources on the XO.
>>
>>> It would only work on Linux, but since that is a dependency of Sugar I
>>> can't see how non-portability would be an issue.  The code gracefully
>>> degrades if /proc entries are not present.
>>>
>>> It uses documented Linux kernel interfaces, which may be invalidated in
>>> future, but those interfaces have lasted a long time without significant
>>> change, and there are many tools that depend on these interfaces.
>>>
>>>> Now, I seem to be the only one concerned about this [...]
>>>
>>> I'd be more concerned about your concern if I could understand how you
>>> drew your conclusions about the function not working without being tuned
>>> to very specific systems.
>>
>> Have you tried it out in something other than the XO?
>>
>>>> When people start complaining about their faces being always happy or
>>>> sad I expect you to help out.
>>>
>>> As a general rule, I would expect no help from coders who contributed
>>> code to an open source project in the past, but help is always welcome,
>>> and the contributor could be one of the first people to be asked when
>>> code breaks.
>>
>> As a general rule, code that depends on heuristics that are tuned to a
>> specific system wouldn't be accepted because would be very hard to
>> support. But I don't have enough time nor energy to discuss things
>> without end.
>
> And this is precisely why we have Dextrose.... When deployments want
> something and upstream doesn't, the patch goes into Dextrose.  No
> harm. No foul.
>
> david
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

-- 
Anish