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() t
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 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 b
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.
>
> Tilm
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 a
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.
> Imagin
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.
>
> Tilm
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 t
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
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
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 ot
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
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 t
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
> >
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
> >
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
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
man it gets annoying people blaming x11 for memory problems. it is rarel
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
> close
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
>> 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 cra
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
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 thinkin
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
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 harmless
> 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
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
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]> writ
> 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 usin
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 overcomm
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 cle
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 ju
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 swa
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
> >
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)
>
>
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
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,
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 some
Carsten Haitzler (The Rasterman) wrote:
>> As i said, swap on flash sound crazy. But i had this experience on my
>> Nokia 770 (64Mb RAM). Even if i was not always on the memory limit, it
>> felt instantaneously better and more stable.
>
> i think its just the lazy mans way out. "there's a probl
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.
> > 1
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! :
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 tha
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
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 sign of "stupid programming" :)
> Looks li
Looks like we need swap after all.
Swap on flash sounds crazy, but this would be a place where non live
pages can be dumped. I assume the majority of the memory that causes
problems like this is leaked memory or regular bloat.
There seem to be some proposals how to make oom-kill behave more
coo
I am running ASU on my FreeRunner. After it being up for a day or two,
things (like the touch screen) stops working. ight now it has been up
for:
[EMAIL PROTECTED]:~# uptime
22:53:34 up 3 days, 5:10, 2 users, load average: 1.01, 1.15, 1.28
[EMAIL PROTECTED]:~#
>From logread:
Aug 20 22:11:47 o
45 matches
Mail list logo
