On Thu, 27 Aug 2015, Michal Hocko wrote:
> > If Andrew would prefer moving in a direction where all Linux users are
> > required to have their admin use sysrq+f to manually trigger an oom kill,
> > which may or may not resolve the livelock since there's no way to
> > determine which process is
On Wed 26-08-15 15:23:07, David Rientjes wrote:
> On Wed, 26 Aug 2015, Michal Hocko wrote:
>
> > > Because the company I work for has far too many machines for that to be
> > > possible.
> >
> > OK I can see that manual intervention for hundreds of machines is not
> > practical. But not everybod
On Wed, 26 Aug 2015, Michal Hocko wrote:
> > Because the company I work for has far too many machines for that to be
> > possible.
>
> OK I can see that manual intervention for hundreds of machines is not
> practical. But not everybody is that large and there are users who might
> want to be be
On Tue 25-08-15 16:41:29, David Rientjes wrote:
> On Tue, 25 Aug 2015, Michal Hocko wrote:
>
> > > I don't believe a solution that requires admin intervention is
> > > maintainable.
> >
> > Why?
> >
>
> Because the company I work for has far too many machines for that to be
> possible.
OK I
On Tue, 25 Aug 2015, Michal Hocko wrote:
> > I don't believe a solution that requires admin intervention is
> > maintainable.
>
> Why?
>
Because the company I work for has far too many machines for that to be
possible.
> > It would be better to reboot when memory reserves are fully depleted.
On Mon 24-08-15 14:10:10, David Rientjes wrote:
> On Fri, 21 Aug 2015, Tetsuo Handa wrote:
>
> > Why can't we think about choosing more OOM victims instead of granting
> > access
> > to memory reserves?
> >
>
> We have no indication of which thread is holding a mutex that would need
> to be ki
On Mon 24-08-15 14:04:28, David Rientjes wrote:
> On Fri, 21 Aug 2015, Michal Hocko wrote:
>
> > There might be many threads waiting for the allocation and this can lead
> > to quick oom reserves depletion without releasing resources which are
> > holding back the oom victim. As Tetsuo has shown,
On Fri, 21 Aug 2015, Tetsuo Handa wrote:
> Why can't we think about choosing more OOM victims instead of granting access
> to memory reserves?
>
We have no indication of which thread is holding a mutex that would need
to be killed, so we'd be randomly killing processes waiting for forward
prog
On Fri, 21 Aug 2015, Michal Hocko wrote:
> There might be many threads waiting for the allocation and this can lead
> to quick oom reserves depletion without releasing resources which are
> holding back the oom victim. As Tetsuo has shown, such a load can be
> generated from the userspace without
Michal Hocko wrote:
> [CCing Tetsuo - he was really concerned about the oom deadlocks and he
> was proposing a timeout based solution as well]
Thank you for CCing me.
My proposal is
http://lkml.kernel.org/r/201505232339.dab00557.vfflhmsojfo...@i-love.sakura.ne.jp
.
>
> On Thu 20-08-15 14:00:3
[CCing Tetsuo - he was really concerned about the oom deadlocks and he
was proposing a timeout based solution as well]
On Thu 20-08-15 14:00:36, David Rientjes wrote:
> On system oom, a process may fail to exit if its thread depends on a lock
> held by another allocating process.
>
> In this cas
On Thu, 20 Aug 2015 14:00:36 -0700 (PDT) David Rientjes
wrote:
> On system oom, a process may fail to exit if its thread depends on a lock
> held by another allocating process.
>
> In this case, we can detect an oom kill livelock that requires memory
> allocation to be successful to resolve.
>
12 matches
Mail list logo
