On 2014/3/6 10:52, David Rientjes wrote:
> On Wed, 5 Mar 2014, Andrew Morton wrote:
>
>>> This patchset introduces a standard interface through memcg that allows
>>> both of these conditions to be handled in the same clean way: users
>>> define memory.oom_reserve_in_bytes to define the reserve an
On Thu 06-03-14 16:33:24, Tejun Heo wrote:
> A bit of addition.
>
> On Thu, Mar 06, 2014 at 01:23:57PM -0800, David Rientjes wrote:
> > This patchset provides a solution to a real-world problem that is not
> > solved with any other patchset. I expect it to be reviewed as any other
> > patchset,
A bit of addition.
On Thu, Mar 06, 2014 at 01:23:57PM -0800, David Rientjes wrote:
> This patchset provides a solution to a real-world problem that is not
> solved with any other patchset. I expect it to be reviewed as any other
> patchset, it's not an "RFC" from my perspective: it's a proposal
On Thu, Mar 06, 2014 at 01:23:57PM -0800, David Rientjes wrote:
> I'm referring to system oom handling as an example above, in case you
> missed my earlier email a few minutes ago: the previous patchset did not
> include support for system oom handling. Nothing that I wrote above was
> possible
On Thu, 6 Mar 2014, Tejun Heo wrote:
> > I'm not sure how you reach that conclusion: it's necessary because any
> > process handling the oom condition will need memory to do anything useful.
> > How else would a process that is handling a system oom condition, for
> > example, be able to obtai
Hello, David.
On Thu, Mar 06, 2014 at 01:08:10PM -0800, David Rientjes wrote:
> I'm not sure how you reach that conclusion: it's necessary because any
> process handling the oom condition will need memory to do anything useful.
> How else would a process that is handling a system oom condition,
On Thu, 6 Mar 2014, Tejun Heo wrote:
> > This includes system oom handling alongside memcg oom handling. If you
> > have specific objections, please let us know, thanks!
>
> Umm, that wasn't the bulk of objection, was it? We were discussion
> the whole premise of userland oom handling and the
On Thu, Mar 06, 2014 at 12:55:43PM -0800, David Rientjes wrote:
> > ISTR the conclusion last time was nack on the whole approach. What
> > changed between then and now? I can't detect any fundamental changes
> > from the description.
> >
>
> This includes system oom handling alongside memcg oom
On Thu, 6 Mar 2014, Tejun Heo wrote:
> On Tue, Mar 04, 2014 at 07:58:38PM -0800, David Rientjes wrote:
> > This patchset implements userspace out of memory handling.
> >
> > It is based on v3.14-rc5. Individual patches will apply cleanly or you
> > may pull the entire series from
> >
> > gi
On Tue, Mar 04, 2014 at 07:58:38PM -0800, David Rientjes wrote:
> This patchset implements userspace out of memory handling.
>
> It is based on v3.14-rc5. Individual patches will apply cleanly or you
> may pull the entire series from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rientj
On Wed, 5 Mar 2014, Andrew Morton wrote:
> > This patchset introduces a standard interface through memcg that allows
> > both of these conditions to be handled in the same clean way: users
> > define memory.oom_reserve_in_bytes to define the reserve and this
> > amount is allowed to be overcharged
On Tue, 4 Mar 2014 19:58:38 -0800 (PST) David Rientjes
wrote:
> This patchset implements userspace out of memory handling.
>
> It is based on v3.14-rc5. Individual patches will apply cleanly or you
> may pull the entire series from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rient
This patchset implements userspace out of memory handling.
It is based on v3.14-rc5. Individual patches will apply cleanly or you
may pull the entire series from
git://git.kernel.org/pub/scm/linux/kernel/git/rientjes/linux.git mm/oom
When the system or a memcg is oom, processes running
13 matches
Mail list logo
