On Wed, Nov 14, 2012 at 02:59:30PM +0100, Michal Hocko wrote:
> On Tue 13-11-12 16:10:41, Johannes Weiner wrote:
> > Would it make sense to stick a wait_on_page_locked() in there just so
> > that we don't busy spin on a page under migration/reclaim?
>
> Hmm, this would also mean that
On Tue 13-11-12 16:10:41, Johannes Weiner wrote:
> On Tue, Oct 30, 2012 at 11:35:59AM +0100, Michal Hocko wrote:
> > On Mon 29-10-12 15:00:22, Andrew Morton wrote:
> > > On Mon, 29 Oct 2012 17:58:45 +0400
> > > Glauber Costa wrote:
> > >
> > > > > + * move charges to its parent or the root
On Tue 13-11-12 16:10:41, Johannes Weiner wrote:
On Tue, Oct 30, 2012 at 11:35:59AM +0100, Michal Hocko wrote:
On Mon 29-10-12 15:00:22, Andrew Morton wrote:
On Mon, 29 Oct 2012 17:58:45 +0400
Glauber Costa glom...@parallels.com wrote:
+ * move charges to its parent or the root
On Wed, Nov 14, 2012 at 02:59:30PM +0100, Michal Hocko wrote:
On Tue 13-11-12 16:10:41, Johannes Weiner wrote:
Would it make sense to stick a wait_on_page_locked() in there just so
that we don't busy spin on a page under migration/reclaim?
Hmm, this would also mean that
On Tue, Oct 30, 2012 at 11:35:59AM +0100, Michal Hocko wrote:
> On Mon 29-10-12 15:00:22, Andrew Morton wrote:
> > On Mon, 29 Oct 2012 17:58:45 +0400
> > Glauber Costa wrote:
> >
> > > > + * move charges to its parent or the root cgroup if the group has no
> > > > + * parent (aka
On Tue, Oct 30, 2012 at 11:35:59AM +0100, Michal Hocko wrote:
On Mon 29-10-12 15:00:22, Andrew Morton wrote:
On Mon, 29 Oct 2012 17:58:45 +0400
Glauber Costa glom...@parallels.com wrote:
+ * move charges to its parent or the root cgroup if the group has no
+ * parent (aka
On Tue, 30 Oct 2012 11:35:59 +0100
Michal Hocko wrote:
> > If the kernel is uniprocessor and the caller is SCHED_FIFO: ad infinitum!
>
> ...
>
> Can we consider this as a corner case (it is much easier to kill a
> machine with SCHED_FIFO than this anyway) or the concern is really
> strong and we
On Tue, 30 Oct 2012 11:35:59 +0100
Michal Hocko mho...@suse.cz wrote:
If the kernel is uniprocessor and the caller is SCHED_FIFO: ad infinitum!
...
Can we consider this as a corner case (it is much easier to kill a
machine with SCHED_FIFO than this anyway) or the concern is really
strong
On Mon 29-10-12 15:00:22, Andrew Morton wrote:
> On Mon, 29 Oct 2012 17:58:45 +0400
> Glauber Costa wrote:
>
> > > + * move charges to its parent or the root cgroup if the group has no
> > > + * parent (aka use_hierarchy==0).
> > > + * Although this might fail (get_page_unless_zero,
On Mon 29-10-12 15:00:22, Andrew Morton wrote:
On Mon, 29 Oct 2012 17:58:45 +0400
Glauber Costa glom...@parallels.com wrote:
+ * move charges to its parent or the root cgroup if the group has no
+ * parent (aka use_hierarchy==0).
+ * Although this might fail (get_page_unless_zero,
On Mon, 29 Oct 2012 17:58:45 +0400
Glauber Costa wrote:
> > + * move charges to its parent or the root cgroup if the group has no
> > + * parent (aka use_hierarchy==0).
> > + * Although this might fail (get_page_unless_zero, isolate_lru_page or
> > + * mem_cgroup_move_account fails) the failure
>>> + * move charges to its parent or the root cgroup if the group has no
>>> + * parent (aka use_hierarchy==0).
>>> + * Although this might fail (get_page_unless_zero, isolate_lru_page or
>>> + * mem_cgroup_move_account fails) the failure is always temporary and
>>> + * it signals a race with a
On Mon 29-10-12 17:58:45, Glauber Costa wrote:
>
> >
> > Changes since v1
> > - use kerndoc
> > - be more specific about mem_cgroup_move_parent possible failures
> >
> > Signed-off-by: Michal Hocko
> > Reviewed-by: Tejun Heo
> Reviewed-by: Glauber Costa
Thanks!
> > + * move charges to its
>
> Changes since v1
> - use kerndoc
> - be more specific about mem_cgroup_move_parent possible failures
>
> Signed-off-by: Michal Hocko
> Reviewed-by: Tejun Heo
Reviewed-by: Glauber Costa
> + * move charges to its parent or the root cgroup if the group has no
> + * parent (aka
On Mon, 29 Oct 2012 17:58:45 +0400
Glauber Costa glom...@parallels.com wrote:
+ * move charges to its parent or the root cgroup if the group has no
+ * parent (aka use_hierarchy==0).
+ * Although this might fail (get_page_unless_zero, isolate_lru_page or
+ * mem_cgroup_move_account fails)
Changes since v1
- use kerndoc
- be more specific about mem_cgroup_move_parent possible failures
Signed-off-by: Michal Hocko mho...@suse.cz
Reviewed-by: Tejun Heo t...@kernel.org
Reviewed-by: Glauber Costa glom...@parallels.com
+ * move charges to its parent or the root cgroup if the
On Mon 29-10-12 17:58:45, Glauber Costa wrote:
Changes since v1
- use kerndoc
- be more specific about mem_cgroup_move_parent possible failures
Signed-off-by: Michal Hocko mho...@suse.cz
Reviewed-by: Tejun Heo t...@kernel.org
Reviewed-by: Glauber Costa glom...@parallels.com
+ * move charges to its parent or the root cgroup if the group has no
+ * parent (aka use_hierarchy==0).
+ * Although this might fail (get_page_unless_zero, isolate_lru_page or
+ * mem_cgroup_move_account fails) the failure is always temporary and
+ * it signals a race with a page
mem_cgroup_force_empty_list currently tries to remove all pages from
the given LRU. To prevent from temoporary failures (EBUSY returned by
mem_cgroup_move_parent) it uses a margin to the current LRU pages and
returns the true if there are still some pages left on the list.
If we consider that
mem_cgroup_force_empty_list currently tries to remove all pages from
the given LRU. To prevent from temoporary failures (EBUSY returned by
mem_cgroup_move_parent) it uses a margin to the current LRU pages and
returns the true if there are still some pages left on the list.
If we consider that
20 matches
Mail list logo
