2010/8/11 NoiseEHC noise...@freemail.hu:
We used to do that, the problem is that we don't control our platform
as Google controls Android and you need to make sure that resources
that need to be specific of each child process aren't shared (dbus and
X connections, etc).
I'm personally more
Hi James,
On 11 Aug 2010, at 04:05, James Cameron wrote:
On Tue, Aug 10, 2010 at 05:48:00PM -0700, John Gilmore wrote:
... and was also unsuccessful in convincing OLPC to prelink the shared
libraries before shipping a release, thus allowing read-only pages to
not get dirtied with shared
gary wrote:
P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see
anything about it in the build notes for either os850 or os851), and I'll
look
silly for trying to test for a difference, confirming my results were non
significant ;-)
that's exactly right.
On 11 Aug 2010, at 18:42, Paul Fox p...@laptop.org wrote:
gary wrote:
P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see
anything about it in the build notes for either os850 or os851), and I'll
look
silly for trying to test for a difference, confirming my
We used to do that, the problem is that we don't control our platform
as Google controls Android and you need to make sure that resources
that need to be specific of each child process aren't shared (dbus and
X connections, etc).
I'm personally more interested in reducing the amount of
I didn't do as detailed an analysis as NoiseEHC - I looked at dirty
page frames, and realized that a large part of RAM was filling with
dirtied pages (even dirtied pages of executables, which get patched to
fill in shared library linkages). Without swap, this left very few
page frames for
2010/8/10 NoiseEHC noise...@freemail.hu:
We used to do that, the problem is that we don't control our platform
as Google controls Android and you need to make sure that resources
that need to be specific of each child process aren't shared (dbus and
X connections, etc).
I'm personally more
On Tue, Aug 10, 2010 at 05:48:00PM -0700, John Gilmore wrote:
... and was also unsuccessful in convincing OLPC to prelink the shared
libraries before shipping a release, thus allowing read-only pages to
not get dirtied with shared library linkage relocations.
10.1.2 release candidate os851 has
On 11 Aug 2010, at 01:56, Lucian Branescu lucian.brane...@gmail.com wrote:
2010/8/10 NoiseEHC noise...@freemail.hu:
We used to do that, the problem is that we don't control our platform
as Google controls Android and you need to make sure that resources
that need to be specific of each
On 9 August 2010 11:25, Bert Freudenberg b...@freudenbergs.de wrote:
On 09.08.2010, at 01:21, John Gilmore wrote:
As long as activities are saving and restoring properly it could be
made pretty much transparent to the user. Of course that's easier
said then done...
Android has a whole
On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote:
Sugar has a similar mechanism. From the Low-level Activity API docs:
org.laptop.Activity.SetActive(b: active)
Activate or passivate an activity. This is sent when switching activities,
there is only one active activity at a time,
On Mon, Aug 9, 2010 at 15:47, Lucian Branescu lucian.brane...@gmail.com wrote:
On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote:
Sugar has a similar mechanism. From the Low-level Activity API docs:
org.laptop.Activity.SetActive(b: active)
Activate or passivate an activity. This is
On 8 Aug 2010, at 01:37, Marco Pesenti Gritti ma...@marcopg.org wrote:
On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com wrote:
Just killing a random activity is a terrible idea becayse you don't want
your product behaving like it's defective; the pop up idea is way more
On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
I tihnk I have been sloppy with my words, so let me clarify two things:
- killing processes should be done only to avoid OOM (because
currently the kernel kills the wrong thing most of the time).
Can't we just _close it
On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote:
On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
I tihnk I have been sloppy with my words, so let me clarify two things:
- killing processes should be done only to avoid OOM (because
On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
Can't we just _close it nicely_?
When you are about to get into OOM?
Early on so we avoid OOM for most cases. Right now our OOM use cases
have nothing to do with misbehaved activities.
Once you're in about to get into
On Sun, Aug 8, 2010 at 8:42 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
Can't we just _close it nicely_?
When you are about to get into OOM?
Early on so we avoid OOM for most cases. Right now our OOM use cases
On Sun, Aug 8, 2010 at 11:42 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
(Not sure what the
state of play is with seeding the OOM scores from userland).
http://linux-mm.org/OOM_Killer
The pid of the activity should have its oomadj bumped up a bit -- so
OOM knows to spare sugar-shell
On Sun, Aug 8, 2010 at 17:42, Martin Langhoff martin.langh...@gmail.com wrote:
On Sun, Aug 8, 2010 at 9:33 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
Can't we just _close it nicely_?
When you are about to get into OOM?
Early on so we avoid OOM for most cases. Right now our OOM use cases
Hi Tomeu,
in general, I think we are saying the same thing :-)
With one exception -- OOM happens because memory is allocated.
Sugar-shell cannot (and I say should not) try to arbitrage in there.
If we try to do it from sugar-shell, all we can do is poll. If we poll
infrequently, we won't catch
On Sun, Aug 8, 2010 at 18:11, Martin Langhoff martin.langh...@gmail.com wrote:
Hi Tomeu,
in general, I think we are saying the same thing :-)
My impression as well.
With one exception -- OOM happens because memory is allocated.
Sugar-shell cannot (and I say should not) try to arbitrage in
On Sun, Aug 8, 2010 at 12:36 PM, Tomeu Vizoso to...@sugarlabs.org wrote:
Well, we certainly should not poll, I started this thread because
recent kernels have a mechanism for getting notified when a certain
threshold of free memory is reached (see below).
...
On Sun, Aug 8, 2010 at 2:33 PM, Tomeu Vizoso to...@sugarlabs.org wrote:
On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com
wrote:
On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote:
I tihnk I have been sloppy with my words, so let me clarify two
On 8 August 2010 20:33, Marco Pesenti Gritti ma...@marcopg.org wrote:
On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote:
The idea of killing activities with the content closed seems ok but it would
probably be a good idea to have a way to opt out of it for some apps. I'm
On 8 August 2010 20:51, Marco Pesenti Gritti ma...@marcopg.org wrote:
On 8 Aug 2010, at 20:38, Lucian Branescu lucian.brane...@gmail.com wrote:
Imo a confirmation popup would become annoying very quickly. Also if the
user refuses, the kernel will have soon to kill an activity, which is worst.
On 8 Aug 2010, at 20:57, Lucian Branescu lucian.brane...@gmail.com wrote:
Separating the activity from the service would help here. In the case
of music, MPD would use a lot less memory than one of its GUIs.
Right, I was thinking to something along these lines too. I'm not sure how
the
26 matches
Mail list logo
