[Sorry, this slipped through cracks]
On Mon 24-08-20 12:58:50, Johannes Weiner wrote:
> On Fri, Aug 21, 2020 at 09:37:16PM +0200, Peter Zijlstra wrote:
[...]
> > Arguably seeing the rate drop to near 0 is a very good point to consider
> > running cgroup-OOM.
>
> Agreed. In the past, that's actual
Johannes Weiner writes:
That all being said, the semantics of the new 'high' limit in cgroup2
have allowed us to move reclaim/limit enforcement out of the
allocation context and into the userspace return path.
See the call to mem_cgroup_handle_over_high() from
tracehook_notify_resume(), and the
On Fri, Aug 21, 2020 at 09:37:16PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 18, 2020 at 09:49:00AM -0400, Johannes Weiner wrote:
> > On Tue, Aug 18, 2020 at 12:18:44PM +0200, pet...@infradead.org wrote:
> > > What you need is a feeback loop against the rate of freeing pages, and
> > > when you ne
On 8/18/20 6:17 AM, Chris Down wrote:
pet...@infradead.org writes:
But then how can it run-away like Waiman suggested?
Probably because he's not running with that commit at all. We and
others use this to prevent runaway allocation on a huge range of
production and desktop use cases and it wo
On Tue, Aug 18, 2020 at 09:49:00AM -0400, Johannes Weiner wrote:
> On Tue, Aug 18, 2020 at 12:18:44PM +0200, pet...@infradead.org wrote:
> > What you need is a feeback loop against the rate of freeing pages, and
> > when you near the saturation point, the allocation rate should exactly
> > match th
On Tue, Aug 18, 2020 at 01:55:59PM +0100, Matthew Wilcox wrote:
> On Tue, Aug 18, 2020 at 12:04:44PM +0200, pet...@infradead.org wrote:
> > On Tue, Aug 18, 2020 at 10:27:37AM +0100, Chris Down wrote:
> > > pet...@infradead.org writes:
> > > > On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wr
On 8/18/20 5:27 AM, Chris Down wrote:
pet...@infradead.org writes:
On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "memory.high" in
a v2 non-root memory cgroup, t
On 8/18/20 5:14 AM, pet...@infradead.org wrote:
On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "memory.high" in
a v2 non-root memory cgroup, the memory controller
On 8/17/20 3:26 PM, Michal Hocko wrote:
On Mon 17-08-20 11:55:37, Waiman Long wrote:
On 8/17/20 11:26 AM, Michal Hocko wrote:
On Mon 17-08-20 10:08:23, Waiman Long wrote:
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "me
On Tue, Aug 18, 2020 at 12:18:44PM +0200, pet...@infradead.org wrote:
> What you need is a feeback loop against the rate of freeing pages, and
> when you near the saturation point, the allocation rate should exactly
> match the freeing rate.
IO throttling solves a slightly different problem.
IO o
On Tue, Aug 18, 2020 at 12:04:44PM +0200, pet...@infradead.org wrote:
> On Tue, Aug 18, 2020 at 10:27:37AM +0100, Chris Down wrote:
> > pet...@infradead.org writes:
> > > On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
> > > > Memory controller can be used to control and limit the amou
On Tue, Aug 18, 2020 at 12:30:59PM +0200, Michal Hocko wrote:
> The proposal also aims at much richer interface to define the
> oom behavior.
Oh yeah, I'm not defending any of that prctl() nonsense.
Just saying that from a math / control theory point of view, the current
thing is a abhorrent fail
pet...@infradead.org writes:
On Tue, Aug 18, 2020 at 11:17:56AM +0100, Chris Down wrote:
I'd ask that you understand a bit more about the tradeoffs and intentions of
the patch before rushing in to declare its failure, considering it works
just fine :-)
Clamping the maximal time allows the appl
On Tue 18-08-20 12:18:44, Peter Zijlstra wrote:
> On Tue, Aug 18, 2020 at 12:05:16PM +0200, Michal Hocko wrote:
> > > But then how can it run-away like Waiman suggested?
> >
> > As Chris mentioned in other reply. This functionality is quite new.
> >
> > > /me goes look... and finds MEMCG_MAX_HIG
On Tue, Aug 18, 2020 at 11:17:56AM +0100, Chris Down wrote:
> I'd ask that you understand a bit more about the tradeoffs and intentions of
> the patch before rushing in to declare its failure, considering it works
> just fine :-)
>
> Clamping the maximal time allows the application to take some a
On Tue, Aug 18, 2020 at 12:05:16PM +0200, Michal Hocko wrote:
> > But then how can it run-away like Waiman suggested?
>
> As Chris mentioned in other reply. This functionality is quite new.
>
> > /me goes look... and finds MEMCG_MAX_HIGH_DELAY_JIFFIES.
>
> We can certainly tune a different back
pet...@infradead.org writes:
But then how can it run-away like Waiman suggested?
Probably because he's not running with that commit at all. We and others use
this to prevent runaway allocation on a huge range of production and desktop
use cases and it works just fine.
/me goes look... and
On Tue, Aug 18, 2020 at 10:27:37AM +0100, Chris Down wrote:
> pet...@infradead.org writes:
> > On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
> > > Memory controller can be used to control and limit the amount of
> > > physical memory used by a task. When a limit is set in "memory.hig
On Tue 18-08-20 11:59:10, Peter Zijlstra wrote:
> On Tue, Aug 18, 2020 at 11:26:17AM +0200, Michal Hocko wrote:
> > On Tue 18-08-20 11:14:53, Peter Zijlstra wrote:
> > > On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
> > > > Memory controller can be used to control and limit the amoun
On Tue, Aug 18, 2020 at 11:26:17AM +0200, Michal Hocko wrote:
> On Tue 18-08-20 11:14:53, Peter Zijlstra wrote:
> > On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
> > > Memory controller can be used to control and limit the amount of
> > > physical memory used by a task. When a limit
pet...@infradead.org writes:
On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "memory.high" in
a v2 non-root memory cgroup, the memory controller will try to reclai
On Tue 18-08-20 11:14:53, Peter Zijlstra wrote:
> On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
> > Memory controller can be used to control and limit the amount of
> > physical memory used by a task. When a limit is set in "memory.high" in
> > a v2 non-root memory cgroup, the memory
On Mon, Aug 17, 2020 at 10:08:23AM -0400, Waiman Long wrote:
> Memory controller can be used to control and limit the amount of
> physical memory used by a task. When a limit is set in "memory.high" in
> a v2 non-root memory cgroup, the memory controller will try to reclaim
> memory if the limit ha
On Mon 17-08-20 10:08:23, Waiman Long wrote:
> Memory controller can be used to control and limit the amount of
> physical memory used by a task. When a limit is set in "memory.high" in
> a v2 non-root memory cgroup, the memory controller will try to reclaim
> memory if the limit has been exceeded.
On Mon 17-08-20 11:55:37, Waiman Long wrote:
> On 8/17/20 11:26 AM, Michal Hocko wrote:
> > On Mon 17-08-20 10:08:23, Waiman Long wrote:
> > > Memory controller can be used to control and limit the amount of
> > > physical memory used by a task. When a limit is set in "memory.high" in
> > > a v2 no
On 8/17/20 11:26 AM, Michal Hocko wrote:
On Mon 17-08-20 10:08:23, Waiman Long wrote:
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "memory.high" in
a v2 non-root memory cgroup, the memory controller will try to reclaim
me
Memory controller can be used to control and limit the amount of
physical memory used by a task. When a limit is set in "memory.high" in
a v2 non-root memory cgroup, the memory controller will try to reclaim
memory if the limit has been exceeded. Normally, that will be enough
to keep the physical m
27 matches
Mail list logo
