On Thu, 28 Nov 2013, Michal Hocko wrote:
> > We already have hooks in the kernel oom killer, things like
> > /proc/sys/vm/oom_kill_allocating_task
>
> How would you implement oom_kill_allocating_task in userspace? You do
> not have any context on who is currently allocating or would you rely on
On Thu, 28 Nov 2013, Michal Hocko wrote:
> > Agreed, and I think the big downside of doing it with the loadable module
> > suggestion is that you can't implement such a wide variety of different
> > policies in modules. Each of our users who own a memcg tree on our
> > systems may want to
On Thu, 28 Nov 2013, Michal Hocko wrote:
Agreed, and I think the big downside of doing it with the loadable module
suggestion is that you can't implement such a wide variety of different
policies in modules. Each of our users who own a memcg tree on our
systems may want to have their
On Thu, 28 Nov 2013, Michal Hocko wrote:
We already have hooks in the kernel oom killer, things like
/proc/sys/vm/oom_kill_allocating_task
How would you implement oom_kill_allocating_task in userspace? You do
not have any context on who is currently allocating or would you rely on
On Wed 20-11-13 19:33:00, David Rientjes wrote:
[...]
> Agreed, and I think the big downside of doing it with the loadable module
> suggestion is that you can't implement such a wide variety of different
> policies in modules. Each of our users who own a memcg tree on our
> systems may want to
On Mon 25-11-13 17:29:20, David Rientjes wrote:
> On Wed, 20 Nov 2013, Luigi Semenzato wrote:
>
> > Yes, I agree that we can't always prevent OOM situations, and in fact
> > we tolerate OOM kills, although they have a worse impact on the users
> > than controlled freeing does.
> >
>
> If the
On Fri 22-11-13 13:08:35, Johannes Weiner wrote:
> On Wed, Nov 20, 2013 at 11:03:33PM -0800, Luigi Semenzato wrote:
> > On Wed, Nov 20, 2013 at 7:36 PM, David Rientjes wrote:
> > > On Wed, 20 Nov 2013, Luigi Semenzato wrote:
> > >
> > >> Chrome OS uses a custom low-memory notification to minimize
On Fri 22-11-13 13:08:35, Johannes Weiner wrote:
On Wed, Nov 20, 2013 at 11:03:33PM -0800, Luigi Semenzato wrote:
On Wed, Nov 20, 2013 at 7:36 PM, David Rientjes rient...@google.com wrote:
On Wed, 20 Nov 2013, Luigi Semenzato wrote:
Chrome OS uses a custom low-memory notification to
On Mon 25-11-13 17:29:20, David Rientjes wrote:
On Wed, 20 Nov 2013, Luigi Semenzato wrote:
Yes, I agree that we can't always prevent OOM situations, and in fact
we tolerate OOM kills, although they have a worse impact on the users
than controlled freeing does.
If the controlled
On Wed 20-11-13 19:33:00, David Rientjes wrote:
[...]
Agreed, and I think the big downside of doing it with the loadable module
suggestion is that you can't implement such a wide variety of different
policies in modules. Each of our users who own a memcg tree on our
systems may want to
On Thu, 21 Nov 2013, Michal Hocko wrote:
> > It's an interesting idea but unfortunately a non-starter for us because
> > our users don't have root,
>
> I wouldn't see this as a problem. You can still have a module which
> exports the notification interface you need. Including timeout
>
On Thu, 21 Nov 2013, Jörn Engel wrote:
> One ancient option I sometime miss was this:
> - Kill the biggest process.
>
That's what both the system and memcg oom killer currently do unless you
change how "biggest process" is defined with /proc/pid/oom_score_adj. The
goal is the kill a
On Wed, 20 Nov 2013, Luigi Semenzato wrote:
> Yes, I agree that we can't always prevent OOM situations, and in fact
> we tolerate OOM kills, although they have a worse impact on the users
> than controlled freeing does.
>
If the controlled freeing is able to actually free memory in time before
On Wed, 20 Nov 2013, Luigi Semenzato wrote:
Yes, I agree that we can't always prevent OOM situations, and in fact
we tolerate OOM kills, although they have a worse impact on the users
than controlled freeing does.
If the controlled freeing is able to actually free memory in time before
On Thu, 21 Nov 2013, Jörn Engel wrote:
One ancient option I sometime miss was this:
- Kill the biggest process.
That's what both the system and memcg oom killer currently do unless you
change how biggest process is defined with /proc/pid/oom_score_adj. The
goal is the kill a single
On Thu, 21 Nov 2013, Michal Hocko wrote:
It's an interesting idea but unfortunately a non-starter for us because
our users don't have root,
I wouldn't see this as a problem. You can still have a module which
exports the notification interface you need. Including timeout
fallback. That
On Wed, Nov 20, 2013 at 11:03:33PM -0800, Luigi Semenzato wrote:
> On Wed, Nov 20, 2013 at 7:36 PM, David Rientjes wrote:
> > On Wed, 20 Nov 2013, Luigi Semenzato wrote:
> >
> >> Chrome OS uses a custom low-memory notification to minimize OOM kills.
> >> When the notifier triggers, the Chrome
On Fri 22-11-13 08:28:03, Vladimir Murzin wrote:
> On Wed, Nov 20, 2013 at 06:33:57PM +0100, Michal Hocko wrote: > On Wed
> 20-11-13 18:21:23, Vladimir Murzin wrote: > > On Tue, Nov 19, 2013 at
> 02:40:07PM +0100, Michal Hocko wrote: > > Hi Michal > > > On Tue 19-11-13
> 14:14:00, Michal Hocko
On Fri 22-11-13 08:28:03, Vladimir Murzin wrote:
On Wed, Nov 20, 2013 at 06:33:57PM +0100, Michal Hocko wrote: On Wed
20-11-13 18:21:23, Vladimir Murzin wrote: On Tue, Nov 19, 2013 at
02:40:07PM +0100, Michal Hocko wrote: Hi MichalOn Tue 19-11-13
14:14:00, Michal Hocko wrote:
On Wed, Nov 20, 2013 at 11:03:33PM -0800, Luigi Semenzato wrote:
On Wed, Nov 20, 2013 at 7:36 PM, David Rientjes rient...@google.com wrote:
On Wed, 20 Nov 2013, Luigi Semenzato wrote:
Chrome OS uses a custom low-memory notification to minimize OOM kills.
When the notifier triggers, the
On Wed, Nov 20, 2013 at 06:33:57PM +0100, Michal Hocko wrote: > On Wed
20-11-13 18:21:23, Vladimir Murzin wrote: > > On Tue, Nov 19, 2013 at
02:40:07PM +0100, Michal Hocko wrote: > > Hi Michal > > > On Tue 19-11-13
14:14:00, Michal Hocko wrote:
> > > [...]
> > > > We have basically ended up with 3
On Wed, Nov 20, 2013 at 06:33:57PM +0100, Michal Hocko wrote: On Wed
20-11-13 18:21:23, Vladimir Murzin wrote: On Tue, Nov 19, 2013 at
02:40:07PM +0100, Michal Hocko wrote: Hi MichalOn Tue 19-11-13
14:14:00, Michal Hocko wrote:
[...]
We have basically ended up with 3 options AFAIR:
On Wed 20-11-13 18:21:23, Vladimir Murzin wrote:
> On Tue, Nov 19, 2013 at 02:40:07PM +0100, Michal Hocko wrote:
> Hi Michal
> > On Tue 19-11-13 14:14:00, Michal Hocko wrote:
> > [...]
> > > We have basically ended up with 3 options AFAIR:
> > > 1) allow memcg approach (memcg.oom_control) on the
Hi David
On Wed, Nov 20, 2013 at 12:02:20AM -0800, David Rientjes wrote:
> On Tue, 19 Nov 2013, Michal Hocko wrote:
>
> > > We have basically ended up with 3 options AFAIR:
> > > 1) allow memcg approach (memcg.oom_control) on the root level
> > >for both OOM notification and
On Tue, Nov 19, 2013 at 02:40:07PM +0100, Michal Hocko wrote:
Hi Michal
> On Tue 19-11-13 14:14:00, Michal Hocko wrote:
> [...]
> > We have basically ended up with 3 options AFAIR:
> > 1) allow memcg approach (memcg.oom_control) on the root level
> >for both OOM notification and
On Wed, Nov 20, 2013 at 7:22 AM, Michal Hocko wrote:
> On Wed 20-11-13 00:02:20, David Rientjes wrote:
>> On Tue, 19 Nov 2013, Michal Hocko wrote:
>>
>> > > We have basically ended up with 3 options AFAIR:
>> > > 1) allow memcg approach (memcg.oom_control) on the root level
>> > >
On Wed 20-11-13 00:02:20, David Rientjes wrote:
> On Tue, 19 Nov 2013, Michal Hocko wrote:
>
> > > We have basically ended up with 3 options AFAIR:
> > > 1) allow memcg approach (memcg.oom_control) on the root level
> > >for both OOM notification and blocking OOM killer and handle
>
On Tue, 19 Nov 2013, Michal Hocko wrote:
> > We have basically ended up with 3 options AFAIR:
> > 1) allow memcg approach (memcg.oom_control) on the root level
> >for both OOM notification and blocking OOM killer and handle
> >the situation from the userspace same as
On Tue, 19 Nov 2013, Michal Hocko wrote:
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
for both OOM notification and blocking OOM killer and handle
the situation from the userspace same as we can
On Wed 20-11-13 00:02:20, David Rientjes wrote:
On Tue, 19 Nov 2013, Michal Hocko wrote:
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
for both OOM notification and blocking OOM killer and handle
On Wed, Nov 20, 2013 at 7:22 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 20-11-13 00:02:20, David Rientjes wrote:
On Tue, 19 Nov 2013, Michal Hocko wrote:
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
for
On Tue, Nov 19, 2013 at 02:40:07PM +0100, Michal Hocko wrote:
Hi Michal
On Tue 19-11-13 14:14:00, Michal Hocko wrote:
[...]
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
for both OOM notification and blocking
Hi David
On Wed, Nov 20, 2013 at 12:02:20AM -0800, David Rientjes wrote:
On Tue, 19 Nov 2013, Michal Hocko wrote:
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
for both OOM notification and blocking OOM
On Wed 20-11-13 18:21:23, Vladimir Murzin wrote:
On Tue, Nov 19, 2013 at 02:40:07PM +0100, Michal Hocko wrote:
Hi Michal
On Tue 19-11-13 14:14:00, Michal Hocko wrote:
[...]
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
On Tue, 19 Nov 2013, Michal Hocko wrote:
> Hi,
> it's been quite some time since LSFMM 2013 when this has been
> discussed[1]. In short, it seems that there are usecases with a
> strong demand on a better user/admin policy control for the global
> OOM situations. Per process oom_{adj,score} which
On Tue 19-11-13 14:14:00, Michal Hocko wrote:
[...]
> We have basically ended up with 3 options AFAIR:
> 1) allow memcg approach (memcg.oom_control) on the root level
>for both OOM notification and blocking OOM killer and handle
>the situation from the userspace same
Hi,
it's been quite some time since LSFMM 2013 when this has been
discussed[1]. In short, it seems that there are usecases with a
strong demand on a better user/admin policy control for the global
OOM situations. Per process oom_{adj,score} which is used for the
prioritizing is no longer
Hi,
it's been quite some time since LSFMM 2013 when this has been
discussed[1]. In short, it seems that there are usecases with a
strong demand on a better user/admin policy control for the global
OOM situations. Per process oom_{adj,score} which is used for the
prioritizing is no longer
On Tue 19-11-13 14:14:00, Michal Hocko wrote:
[...]
We have basically ended up with 3 options AFAIR:
1) allow memcg approach (memcg.oom_control) on the root level
for both OOM notification and blocking OOM killer and handle
the situation from the userspace same as
On Tue, 19 Nov 2013, Michal Hocko wrote:
Hi,
it's been quite some time since LSFMM 2013 when this has been
discussed[1]. In short, it seems that there are usecases with a
strong demand on a better user/admin policy control for the global
OOM situations. Per process oom_{adj,score} which is
40 matches
Mail list logo
