Tetsuo Handa wrote:
> So, zapping the first OOM victim's mm might fail by chance.
I retested with a slightly different version.
-- Reproducer start --
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
static int writer(void
Tetsuo Handa wrote:
> So, zapping the first OOM victim's mm might fail by chance.
I retested with a slightly different version.
-- Reproducer start --
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
static int writer(void
Tetsuo Handa wrote:
> Without means to find out what was happening, we will "overlook real bugs"
> before "paper over real bugs". The means are expected to work without
> knowledge to use trace points functionality, are expected to run without
> memory allocation, are expected to dump output
Tetsuo Handa wrote:
> Without means to find out what was happening, we will "overlook real bugs"
> before "paper over real bugs". The means are expected to work without
> knowledge to use trace points functionality, are expected to run without
> memory allocation, are expected to dump output
Linus Torvalds wrote:
> Because another thing that tends to affect this is that oom without swap is
> very different from oom with lots of swap, so different people will see
> very different issues. If you have some particular case you want to check,
> and could make a VM image for it, maybe that
Linus Torvalds wrote:
> Because another thing that tends to affect this is that oom without swap is
> very different from oom with lots of swap, so different people will see
> very different issues. If you have some particular case you want to check,
> and could make a VM image for it, maybe that
Tetsuo Handa wrote:
> Sorry. This was my misunderstanding. But I still think that we need to be
> prepared for cases where zapping OOM victim's mm approach fails.
> (
> http://lkml.kernel.org/r/201509242050.ehe95837.fvfootmqhlj...@i-love.sakura.ne.jp
> )
I tested whether it is easy/difficult to
Tetsuo Handa wrote:
> Sorry. This was my misunderstanding. But I still think that we need to be
> prepared for cases where zapping OOM victim's mm approach fails.
> (
> http://lkml.kernel.org/r/201509242050.ehe95837.fvfootmqhlj...@i-love.sakura.ne.jp
> )
I tested whether it is easy/difficult to
Michal Hocko wrote:
> On Tue 29-09-15 01:18:00, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > The point I've tried to made is that oom unmapper running in a detached
> > > context (e.g. kernel thread) vs. directly in the oom context doesn't
> > > make any difference wrt. lock because the
Michal Hocko wrote:
> On Tue 29-09-15 01:18:00, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > The point I've tried to made is that oom unmapper running in a detached
> > > context (e.g. kernel thread) vs. directly in the oom context doesn't
> > > make any difference wrt. lock because the
10 matches
Mail list logo
