On Tue 09-06-15 15:45:35, David Rientjes wrote:
> On Tue, 9 Jun 2015, Michal Hocko wrote:
>
> > > Yes, and that's why I believe we should pursue that direction without the
> > > associated "cleanup" that adds 35 lines of code to supress a panic. In
> > > other words, there's no reason to combin
On Tue, 9 Jun 2015, Michal Hocko wrote:
> > Yes, and that's why I believe we should pursue that direction without the
> > associated "cleanup" that adds 35 lines of code to supress a panic. In
> > other words, there's no reason to combine a patch that suppresses the
> > panic even with panic_o
On Mon 08-06-15 16:06:07, David Rientjes wrote:
> On Mon, 8 Jun 2015, Michal Hocko wrote:
>
> > > This patch is not a functional change, so I don't interpret your feedback
> > > as any support of it being merged.
> >
> > David, have you actually read the patch? The changelog is mentioning this:
On Mon, 8 Jun 2015, Michal Hocko wrote:
> > This patch is not a functional change, so I don't interpret your feedback
> > as any support of it being merged.
>
> David, have you actually read the patch? The changelog is mentioning this:
> "
> check_panic_on_oom on the other hand will work and
On Mon 08-06-15 12:41:48, David Rientjes wrote:
> On Mon, 8 Jun 2015, Austin S Hemmelgarn wrote:
>
> > I believe so (haven't actually read the patch itself, just the changelog),
> > although it is only a change for certain configurations to a very specific
> > and
> > (I hope infrequently) used p
On Mon, 8 Jun 2015, Austin S Hemmelgarn wrote:
> I believe so (haven't actually read the patch itself, just the changelog),
> although it is only a change for certain configurations to a very specific and
> (I hope infrequently) used piece of functionality. Like I said above, if I
> wanted to cras
On 2015-06-08 13:59, David Rientjes wrote:
On Fri, 5 Jun 2015, Austin S Hemmelgarn wrote:
I'm not sure what the benefit of this is, and it's adding more code.
Having multiple pathways and requirements, such as constrained_alloc(), to
oom kill a process isn't any clearer, in my opinion. It also
On Fri, 5 Jun 2015, Austin S Hemmelgarn wrote:
> > I'm not sure what the benefit of this is, and it's adding more code.
> > Having multiple pathways and requirements, such as constrained_alloc(), to
> > oom kill a process isn't any clearer, in my opinion. It also isn't
> > intended to be optimize
On 2015-06-04 18:59, David Rientjes wrote:
On Tue, 2 Jun 2015, Michal Hocko wrote:
OOM killer might be triggered externally via sysrq+f. This is supposed
to kill a task no matter what e.g. a task is selected even though there
is an OOM victim on the way to exit. This is a big hammer for an admi
On Tue, 2 Jun 2015, Michal Hocko wrote:
> OOM killer might be triggered externally via sysrq+f. This is supposed
> to kill a task no matter what e.g. a task is selected even though there
> is an OOM victim on the way to exit. This is a big hammer for an admin
> to help to resolve a memory short co
OOM killer might be triggered externally via sysrq+f. This is supposed
to kill a task no matter what e.g. a task is selected even though there
is an OOM victim on the way to exit. This is a big hammer for an admin
to help to resolve a memory short condition when the system is not able
to cope with
11 matches
Mail list logo
