On Fri, 22 Aug 2008 11:13:19 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
Pardon.
I don't care for the warm and fuzzy feeling you get by having malloc
fail on you.
the problem is.. it doesn't say it failed. it says it succeeded. it returns a
pointer. program now moves on and should be
On Fri, 22 Aug 2008 12:36:52 -0400 Chris Wright [EMAIL PROTECTED] babbled:
On the other hand, let's say your process allocates some memory and
doesn't use it for a while. In the meantime, some memory is freed.
This doesn't help if malloc() returned null, but it does help if the
kernel
On Fri, 22 Aug 2008 16:53:15 +0200 Clemens Kirchgatterer [EMAIL PROTECTED]
babbled:
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote:
Problem is, your might not have the memory to trawl those .desktop
files.
thus my original write a root daemon - setsched() to realtime
On Friday 22 August 2008 02:59:25 Carsten Haitzler wrote:
On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken [EMAIL PROTECTED]
babbled:
For a phone, the algorithm could be as simple as killing the process that
has allocated the most memory. The essential system services and the
basic UI
On Fri, 22 Aug 2008 08:36:26 +0200 Sander van Grieken [EMAIL PROTECTED]
babbled:
On Friday 22 August 2008 02:59:25 Carsten Haitzler wrote:
On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken [EMAIL PROTECTED]
babbled:
For a phone, the algorithm could be as simple as killing the process
Am 22.08.2008 um 02:50 schrieb Carsten Haitzler (The Rasterman):
A 128Mio space of memory is not that huge, especially if you want to
use it for something cool and you will at some points pass this mark
and things will die; given the current algorithm it might not be
something you want to
Pardon.
I don't care for the warm and fuzzy feeling you get by having malloc
fail on you.
It does not give you a bit more system stability! The one app
receiving malloc errors is just not app of many. They all have a
problem then.
Imagine, the browser catches a failed malloc, because some
Am 22.08.2008 um 02:50 schrieb Carsten Haitzler (The Rasterman):
On Thu, 21 Aug 2008 18:49:33 +0200 Tilman Baumann
[EMAIL PROTECTED] babbled:
And come on. Software is not perfect. Sometimes we have to live
with a
dreamteam like (old) firefox and x11. I had times when they had both
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote:
Problem is, your might not have the memory to trawl those .desktop
files.
thus my original write a root daemon - setsched() to realtime
priority and mlock() memory space down! (and of course read every
page of memory to make sure
Tilman Baumann [EMAIL PROTECTED] wrote:
44kbyte are not very impressive, but they prove my point never the
less. This memory is obviously waste. It stays in swap for ages. Not
much saved, but anyhow. It is memory that did not need to be in ram.
Tilman, i agree to most points you made in this
Clemens Kirchgatterer wrote:
Tilman Baumann [EMAIL PROTECTED] wrote:
44kbyte are not very impressive, but they prove my point never the
less. This memory is obviously waste. It stays in swap for ages. Not
much saved, but anyhow. It is memory that did not need to be in ram.
Tilman, i agree
2008/8/22 Tilman Baumann [EMAIL PROTECTED]:
Pardon.
I don't care for the warm and fuzzy feeling you get by having malloc
fail on you.
It does not give you a bit more system stability! The one app
receiving malloc errors is just not app of many. They all have a
problem then.
Imagine, the
2008/8/22 Chris Wright [EMAIL PROTECTED]:
2008/8/22 Tilman Baumann [EMAIL PROTECTED]:
Pardon.
I don't care for the warm and fuzzy feeling you get by having malloc
fail on you.
It does not give you a bit more system stability! The one app
receiving malloc errors is just not app of many. They
Clemens Kirchgatterer wrote:
Tilman Baumann [EMAIL PROTECTED] wrote:
44kbyte are not very impressive, but they prove my point never the
less. This memory is obviously waste. It stays in swap for ages. Not
much saved, but anyhow. It is memory that did not need to be in ram.
Tilman, i agree
look good to me.
Should ASU run out of memory?
--
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman
user.err kernel: [275269.02] Killed
process 1278 (hald-runner)
This doesn't look good to me.
Should ASU run out of memory?
--
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 11:42:52 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
no.. you need to find who is leaking memory and beat them up! :) seriously.
128m is more than enough. it's almost overkill. needing swap (on a device like
the freerunner) is a
On Thu, Aug 21, 2008 at 12:58:44PM +0200, Tilman Baumann wrote:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 11:42:52 +0200 Tilman Baumann [EMAIL PROTECTED]
babbled:
no.. you need to find who is leaking memory and beat them up! :) seriously.
128m is more than enough.
Rui Miguel Silva Seabra wrote:
On Thu, Aug 21, 2008 at 12:58:44PM +0200, Tilman Baumann wrote:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 11:42:52 +0200 Tilman Baumann [EMAIL PROTECTED]
babbled:
no.. you need to find who is leaking memory and beat them up! :) seriously.
On Thu, 21 Aug 2008 12:58:44 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 11:42:52 +0200 Tilman Baumann [EMAIL PROTECTED]
babbled:
no.. you need to find who is leaking memory and beat them up! :) seriously.
128m is more
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of helplessley crashing)
Yes, or killing the application. Not having swap is nonsense;). If you
are using swap
Tilman Baumann wrote:
i'd think it would make little sense so make the system
that fragile. fix the memory usage issue - don't just get more slow slow
slow
ram. :)
As i said, i had made the experience that it improved the system
greatly. Shouldn't we just test it?
Perhaps, that is what
Esben Stien wrote:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of helplessley crashing)
Yes, or killing the application.
That would be great. But was always
On Thu, 21 Aug 2008 17:50:26 +0200 Esben Stien [EMAIL PROTECTED] babbled:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of helplessley crashing)
Yes, or
On Thu, 21 Aug 2008 16:09:58 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
Esben Stien wrote:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of helplessley
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 17:50:26 +0200 Esben Stien [EMAIL PROTECTED] babbled:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of
Carsten Haitzler (The Rasterman) wrote:
I remember there was a proposal for a more intelligent oom killer system
on lkml some time ago. No idea if this is still around.
(Was afaik some preemtive notification to userspace)
Intuitively the answer is clear. Kill the culprit and not just
Tilman Baumann wrote:
Carsten Haitzler (The Rasterman) wrote:
I remember there was a proposal for a more intelligent oom killer system
on lkml some time ago. No idea if this is still around.
(Was afaik some preemtive notification to userspace)
Intuitively the answer is clear. Kill the
On Thu, 21 Aug 2008 16:44:36 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 17:50:26 +0200 Esben Stien [EMAIL PROTECTED]
babbled:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of helplessley crashing)
Yes, or killing the application. Not having swap is nonsense;). If you
are using swap
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 16:44:36 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 17:50:26 +0200 Esben Stien [EMAIL PROTECTED]
babbled:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux
Sander van Grieken wrote:
Tilman Baumann [EMAIL PROTECTED] writes:
all the linux memory overcommit behaviour more or less depends on
the fact that it can allways save it's ass by using swap. (Instead
of helplessley crashing)
Yes, or killing the application. Not having swap is nonsense;). If
And come on. Software is not perfect. Sometimes we have to live with a
dreamteam like (old) firefox and x11. I had times when they had both
hundreds of megs virtual mem. But everything was fine because it all was
just harmlessly been swaped away. I restarted them every weekend to not
let it
On Thursday 21 August 2008 19:33:24 Steven Kurylo wrote:
And come on. Software is not perfect. Sometimes we have to live with a
dreamteam like (old) firefox and x11. I had times when they had both
hundreds of megs virtual mem. But everything was fine because it all was
just harmlessly been
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] writes:
really - we need a userspace oom that is Smarter (it knows what a system
daemon is and what a user application is and what is a necessary user desktop
process), so it will always kill apps not the phone daemon or the window
manager or
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] writes:
and luckily those smart fellas in kernel developer land.. made
kernel overcommit.. a tunable parameter! and... cunningly.. on the
FR (and as wel on my desktop) it's turned off! :) so... a moot point
really. :)
I was more thinking of
Am 21.08.2008 um 19:33 schrieb Steven Kurylo:
And come on. Software is not perfect. Sometimes we have to live
with a
dreamteam like (old) firefox and x11. I had times when they had both
hundreds of megs virtual mem. But everything was fine because it
all was
just harmlessly been swaped
I'm not sure this is true on Freerunner. None of the embedded systems
I've used have had swap.
Because they where really embedded.
Openmoko is more or less a mobile desktop.
Its embedded because of the limited resources available to it.
Slowing down is clearly better than instant crashing.
On Thu, 21 Aug 2008 14:29:45 -0400 Clinton Ebadi [EMAIL PROTECTED]
babbled:
You've just rediscovered one of the few good design decisions of the
l4hurd project. See the bits on memory allocation in [0]. 'Tis a shame
that Hurd has pretty much failed (l4hurd and ngHurd got closer and
closer to
On Fri, 22 Aug 2008 00:07:12 +0200 Esben Stien [EMAIL PROTECTED] babbled:
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] writes:
and luckily those smart fellas in kernel developer land.. made
kernel overcommit.. a tunable parameter! and... cunningly.. on the
FR (and as wel on my
On Thu, 21 Aug 2008 18:40:52 +0200 Tilman Baumann [EMAIL PROTECTED] babbled:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 16:44:36 +0200 Tilman Baumann [EMAIL PROTECTED]
babbled:
Carsten Haitzler (The Rasterman) wrote:
On Thu, 21 Aug 2008 17:50:26 +0200 Esben Stien
On Thu, 21 Aug 2008 19:54:26 +0200 Sander van Grieken [EMAIL PROTECTED]
babbled:
On Thursday 21 August 2008 19:33:24 Steven Kurylo wrote:
And come on. Software is not perfect. Sometimes we have to live with a
dreamteam like (old) firefox and x11. I had times when they had both
hundreds
Aug 20 22:13:23 om-gta02 user.err kernel: [275269.02] Killed
process 1278 (hald-runner)
This doesn't look good to me.
Should ASU run out of memory?
--
Regards,
Torfinn Ingolfsen
___
Openmoko community mailing list
community@lists.openmoko.org
http
43 matches
Mail list logo
