Alan wrote:
> > What I understood from Arjan is that the problem isn't swapspace, but
> > rather that shared-libs are implement via a COW trick, which always
> > overcommits, no matter what.
>
> The zero overcommit layer accounts address space not pages.
So OOM can still occur?
> > Are you saying
> What I understood from Arjan is that the problem isn't swapspace, but rather
> that shared-libs are implement via a COW trick, which always overcommits, no
> matter what.
The zero overcommit layer accounts address space not pages.
> Are you saying there is some new no-overcommit functionality
Alan wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > > That is why we have no-overcommit support.
> >
> > Alan, I think you know that this isn't really true, due to shared-libs.
>
> Shared libraries are correctly handled by no-overcommit and in fact they
> have almost zero impact on out of memory
On Fri, 8 Dec 2006 16:58:29 +0300
Al Boldi <[EMAIL PROTECTED]> wrote:
> > That is why we have no-overcommit support.
>
> Alan, I think you know that this isn't really true, due to shared-libs.
Shared libraries are correctly handled by no-overcommit and in fact they
have almost zero impact on out
Alan wrote:
> > On an embedded platform this allows the designer to engineer the system
> > and protect critical apps based on their expected memory consumption.
> > If one of those apps goes crazy and starts chewing additional memory
> > then it becomes vulnerable to the oom killer while the other
Alan wrote:
The "oom-thresh" value maps to the max expected memory consumption for
that process. As long as a process uses less memory than the specified
threshold, then it is immune to the oom-killer.
You've just introduced a deadlock. What happens if nobody is over that
predicted memory a
> We add a new "oom_thresh" member to the task struct.
> We introduce a new proc entry "/proc//oomthresh" to control it.
>
> The "oom-thresh" value maps to the max expected memory consumption for
> that process. As long as a process uses less memory than the specified
> threshold, then it is im
On 07/12/06, Chris Friesen <[EMAIL PROTECTED]> wrote:
Jesper Juhl wrote:
>> Jesper Juhl wrote:
>> > What happens in the case where the OOM killer really, really needs to
>> > kill one or more processes since there is not a single drop of memory
>> > available, but all processes are below their c
Jesper Juhl wrote:
Jesper Juhl wrote:
> What happens in the case where the OOM killer really, really needs to
> kill one or more processes since there is not a single drop of memory
> available, but all processes are below their configured thresholds?
I realize that if this case happens the
On 07/12/06, Chris Friesen <[EMAIL PROTECTED]> wrote:
Jesper Juhl wrote:
> What happens in the case where the OOM killer really, really needs to
> kill one or more processes since there is not a single drop of memory
> available, but all processes are below their configured thresholds?
Then the
Peter Zijlstra wrote:
On Thu, 2006-12-07 at 12:30 -0600, Chris Friesen wrote:
The "oom-thresh" value maps to the max expected memory consumption for
that process. As long as a process uses less memory than the specified
threshold, then it is immune to the oom-killer.
You would need to spec
Jesper Juhl wrote:
How does "oomthresh" and "oomadj" affect each other?
If memory consumption is less than "oomthresh", that process is simply
bypassed. (Equivalent to oomkilladj==OOM_DISABLE.) Otherwise, continue
processing as normal.
Default "oomthresh" value for a new process is 0 (z
On Thu, 2006-12-07 at 12:30 -0600, Chris Friesen wrote:
> The kernel currently has a way to adjust the oom-killer score via
> /proc//oomadj.
>
> However, to adjust this effectively requires knowledge of the scores of
> all the other processes on the system.
>
> I'd like to float an idea (which
A few questions below.
On 07/12/06, Chris Friesen <[EMAIL PROTECTED]> wrote:
The kernel currently has a way to adjust the oom-killer score via
/proc//oomadj.
However, to adjust this effectively requires knowledge of the scores of
all the other processes on the system.
I'd like to float an ide
The kernel currently has a way to adjust the oom-killer score via
/proc//oomadj.
However, to adjust this effectively requires knowledge of the scores of
all the other processes on the system.
I'd like to float an idea (which we've implemented and been using for
some time) where the semanti
15 matches
Mail list logo
