On Tue 17-05-16 15:21:39, Andrew Morton wrote:
> On Tue, 17 May 2016 22:28:56 +0200 Michal Hocko wrote:
>
> > Andrew, this is not in the mmotm tree now because I didn't feel really
> > confortable with the patch without Oleg seeing it. But it seems Oleg is
> > ok [1] with it so could you push it
On Tue, 17 May 2016 22:28:56 +0200 Michal Hocko wrote:
> Andrew, this is not in the mmotm tree now because I didn't feel really
> confortable with the patch without Oleg seeing it. But it seems Oleg is
> ok [1] with it so could you push it to Linus along with the rest of oom
> pile please?
Reluc
On Tue 26-04-16 15:57:52, Michal Hocko wrote:
> On Tue 12-04-16 11:19:16, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > task_will_free_mem is a misnomer for a more complex PF_EXITING test
> > for early break out from the oom killer because it is believed that
> > such a task would release it
On Tue 17-05-16 20:42:25, Oleg Nesterov wrote:
> On 04/12, Michal Hocko wrote:
> >
> > We shouldn't consider the task
> > unless the whole thread group is going down.
>
> Yes, agreed. I'd even say that oom-killer should never look at individual
> task/threads, it should work with mm's. And one of
On 04/12, Michal Hocko wrote:
>
> We shouldn't consider the task
> unless the whole thread group is going down.
Yes, agreed. I'd even say that oom-killer should never look at individual
task/threads, it should work with mm's. And one of the big mistakes (imo)
was the s/for_each_process/for_each_th
On 04/13, Michal Hocko wrote:
>
> On Wed 13-04-16 20:04:54, Tetsuo Handa wrote:
> > On 2016/04/12 18:19, Michal Hocko wrote:
> [...]
> > > Hi,
> > > I hope I got it right but I would really appreciate if Oleg found some
> > > time and double checked after me. The fix is more cosmetic than anything
On Tue 12-04-16 11:19:16, Michal Hocko wrote:
> From: Michal Hocko
>
> task_will_free_mem is a misnomer for a more complex PF_EXITING test
> for early break out from the oom killer because it is believed that
> such a task would release its memory shortly and so we do not have
> to select an oom
On Wed 13-04-16 22:27:52, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > The whole thread group is going down does not mean we make sure that
> > > we will send SIGKILL to other thread groups sharing the same memory which
> > > is possibly holding mmap_sem for write, does it?
> >
> > And the patc
Michal Hocko wrote:
> > The whole thread group is going down does not mean we make sure that
> > we will send SIGKILL to other thread groups sharing the same memory which
> > is possibly holding mmap_sem for write, does it?
>
> And the patch description doesn't say anything about processes sharing
On Wed 13-04-16 20:04:54, Tetsuo Handa wrote:
> On 2016/04/12 18:19, Michal Hocko wrote:
[...]
> > Hi,
> > I hope I got it right but I would really appreciate if Oleg found some
> > time and double checked after me. The fix is more cosmetic than anything
> > else but I guess it is worth it.
>
> I
On 2016/04/12 18:19, Michal Hocko wrote:
> From: Michal Hocko
>
> task_will_free_mem is a misnomer for a more complex PF_EXITING test
> for early break out from the oom killer because it is believed that
> such a task would release its memory shortly and so we do not have
> to select an oom victi
From: Michal Hocko
task_will_free_mem is a misnomer for a more complex PF_EXITING test
for early break out from the oom killer because it is believed that
such a task would release its memory shortly and so we do not have
to select an oom victim and perform a disruptive action.
Currently we make
12 matches
Mail list logo
