On Wed 13-02-13 11:34:59, Michal Hocko wrote:
> On Tue 12-02-13 12:37:41, Johannes Weiner wrote:
> > On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
> [...]
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index 727ec39..31bb9b0 100644
> > > --- a/mm/memcontrol.c
> > > +++
On Wed 13-02-13 12:11:59, Glauber Costa wrote:
> On 02/12/2013 09:37 PM, Johannes Weiner wrote:
> >> > All reads from root->dead_count are atomic already, so I am not sure
> >> > what you mean here. Anyway, I hope I won't make this even more confusing
> >> > if I post what I have right now:
> >
On Tue 12-02-13 12:37:41, Johannes Weiner wrote:
> On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
[...]
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 727ec39..31bb9b0 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -144,8 +144,13 @@ struct
On Tue 12-02-13 14:53:58, Johannes Weiner wrote:
[...]
> iteration:
> rcu_read_lock()
> dead_count = atomic_read(>dead_count)
> smp_rmb()
> previous = iterator->position
> if (iterator->dead_count != dead_count)
>/* A cgroup in our hierarchy was killed, pointer might be dangling */
>don't
On 02/12/2013 09:37 PM, Johannes Weiner wrote:
>> > All reads from root->dead_count are atomic already, so I am not sure
>> > what you mean here. Anyway, I hope I won't make this even more confusing
>> > if I post what I have right now:
> Yes, but we are doing two reads. Can't the memcg that
On 02/12/2013 09:37 PM, Johannes Weiner wrote:
All reads from root-dead_count are atomic already, so I am not sure
what you mean here. Anyway, I hope I won't make this even more confusing
if I post what I have right now:
Yes, but we are doing two reads. Can't the memcg that we'll store in
On Tue 12-02-13 14:53:58, Johannes Weiner wrote:
[...]
iteration:
rcu_read_lock()
dead_count = atomic_read(hierarchy-dead_count)
smp_rmb()
previous = iterator-position
if (iterator-dead_count != dead_count)
/* A cgroup in our hierarchy was killed, pointer might be dangling */
don't
On Tue 12-02-13 12:37:41, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
[...]
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 727ec39..31bb9b0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -144,8 +144,13 @@ struct mem_cgroup_stat_cpu {
On Wed 13-02-13 12:11:59, Glauber Costa wrote:
On 02/12/2013 09:37 PM, Johannes Weiner wrote:
All reads from root-dead_count are atomic already, so I am not sure
what you mean here. Anyway, I hope I won't make this even more confusing
if I post what I have right now:
Yes, but we are
On Wed 13-02-13 11:34:59, Michal Hocko wrote:
On Tue 12-02-13 12:37:41, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
[...]
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 727ec39..31bb9b0 100644
--- a/mm/memcontrol.c
+++
On Tue, Feb 12, 2013 at 10:31:48AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 12, 2013 at 12:25:26PM -0500, Johannes Weiner wrote:
> > On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
> > > On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> > > > On Tue 12-02-13
On Tue, Feb 12, 2013 at 12:25:26PM -0500, Johannes Weiner wrote:
> On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
> > On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> > > On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> > > > On Tue, Feb 12, 2013 at 10:54:19AM
On Tue 12-02-13 08:10:51, Paul E. McKenney wrote:
> On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> > On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> > > On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> > >
On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> > On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > > On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> > > > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko
On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
> On Tue 12-02-13 11:41:03, Johannes Weiner wrote:
> >
> >
> > Michal Hocko wrote:
> >
> > >On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> > >> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> > >> [...]
> > >> The example was not
On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> > On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> > > On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 17:39:43, Johannes
On Tue 12-02-13 11:41:03, Johannes Weiner wrote:
>
>
> Michal Hocko wrote:
>
> >On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> >> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> >> [...]
> >> The example was not complete:
> >>
> >> > Wait a moment. But what prevents from the following race?
Michal Hocko wrote:
>On Tue 12-02-13 17:13:32, Michal Hocko wrote:
>> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
>> [...]
>> The example was not complete:
>>
>> > Wait a moment. But what prevents from the following race?
>> >
>> > rcu_read_lock()
>>
>> cgroup_next_descendant_pre
>>
On Tue 12-02-13 17:24:42, Michal Hocko wrote:
> On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> > On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> > [...]
> > The example was not complete:
> >
> > > Wait a moment. But what prevents from the following race?
> > >
> > > rcu_read_lock()
> >
> >
Michal Hocko wrote:
>On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
>> On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
>> > On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
>> > > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
>> > > > On Mon 11-02-13 14:58:24,
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
> [...]
> The example was not complete:
>
> > Wait a moment. But what prevents from the following race?
> >
> > rcu_read_lock()
>
> cgroup_next_descendant_pre
> css_tryget(css);
> memcg =
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
> Wait a moment. But what prevents from the following race?
>
> rcu_read_lock()
cgroup_next_descendant_pre
css_tryget(css);
memcg = mem_cgroup_from_css(css)atomic_add(CSS_DEACT_BIAS,
>refcnt)
>
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> > > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > > >
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> > > On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > > > That way, if the dead count gives the go-ahead, you KNOW
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> > On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > > On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> > > > On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> > > >
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
On Mon, Feb
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
That way, if the dead count gives the go-ahead, you KNOW that the
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
That way, if
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
Wait a moment. But what prevents from the following race?
rcu_read_lock()
cgroup_next_descendant_pre
css_tryget(css);
memcg = mem_cgroup_from_css(css)atomic_add(CSS_DEACT_BIAS,
css-refcnt)
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
Wait a moment. But what prevents from the following race?
rcu_read_lock()
cgroup_next_descendant_pre
css_tryget(css);
memcg = mem_cgroup_from_css(css)
Michal Hocko mho...@suse.cz wrote:
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
On Mon 11-02-13 14:58:24,
On Tue 12-02-13 17:24:42, Michal Hocko wrote:
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
Wait a moment. But what prevents from the following race?
rcu_read_lock()
Michal Hocko mho...@suse.cz wrote:
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
Wait a moment. But what prevents from the following race?
rcu_read_lock()
cgroup_next_descendant_pre
On Tue 12-02-13 11:41:03, Johannes Weiner wrote:
Michal Hocko mho...@suse.cz wrote:
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
Wait a moment. But what prevents from the following race?
On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
On Tue 12-02-13 11:41:03, Johannes Weiner wrote:
Michal Hocko mho...@suse.cz wrote:
On Tue 12-02-13 17:13:32, Michal Hocko wrote:
On Tue 12-02-13 16:43:30, Michal Hocko wrote:
[...]
The example was not complete:
On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
On Tue 12-02-13 08:10:51, Paul E. McKenney wrote:
On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
On Mon, Feb
On Tue, Feb 12, 2013 at 12:25:26PM -0500, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 10:54:19AM +0100,
On Tue, Feb 12, 2013 at 10:31:48AM -0800, Paul E. McKenney wrote:
On Tue, Feb 12, 2013 at 12:25:26PM -0500, Johannes Weiner wrote:
On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
On Tue 12-02-13 10:10:02,
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> > > On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> > > > On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko
On Mon 11-02-13 22:27:56, Michal Hocko wrote:
[...]
> I will get back to this tomorrow.
Maybe not a great idea as it is getting late here and brain turns into
cabbage but there we go:
---
>From f927358fe620837081d7a7ec6bf27af378deb35d Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Mon, 11 Feb
On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> > On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> > > On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
> > > > Maybe we could keep the counter per memcg but that would
On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> > On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
> > > Maybe we could keep the counter per memcg but that would mean that we
> > > would need to go up the hierarchy as
On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
> > On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
> > [...]
> > > for each in hierarchy:
> > > for each node:
> > > for each zone:
> > > for each reclaim priority:
> > >
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
> On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
> [...]
> > for each in hierarchy:
> > for each node:
> > for each zone:
> > for each reclaim priority:
> >
> > every time a cgroup is destroyed. I don't think such a
On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
[...]
> for each in hierarchy:
> for each node:
> for each zone:
> for each reclaim priority:
>
> every time a cgroup is destroyed. I don't think such a hammer is
> justified in general, let alone for consolidating code a little.
>
>
On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
[...]
for each in hierarchy:
for each node:
for each zone:
for each reclaim priority:
every time a cgroup is destroyed. I don't think such a hammer is
justified in general, let alone for consolidating code a little.
Can we
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
[...]
for each in hierarchy:
for each node:
for each zone:
for each reclaim priority:
every time a cgroup is destroyed. I don't think such a hammer is
On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
[...]
for each in hierarchy:
for each node:
for each zone:
for each reclaim priority:
every time a
On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
Maybe we could keep the counter per memcg but that would mean that we
would need to go up the hierarchy as well. We
On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
Maybe we could keep the counter per memcg but that would mean that
On Mon 11-02-13 22:27:56, Michal Hocko wrote:
[...]
I will get back to this tomorrow.
Maybe not a great idea as it is getting late here and brain turns into
cabbage but there we go:
---
From f927358fe620837081d7a7ec6bf27af378deb35d Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date:
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
On Thu, Jan 03, 2013 at 06:54:18PM +0100, Michal Hocko wrote:
> Now that per-node-zone-priority iterator caches memory cgroups rather
> than their css ids we have to be careful and remove them from the
> iterator when they are on the way out otherwise they might hang for
> unbounded amount of time
On Thu, Jan 03, 2013 at 06:54:18PM +0100, Michal Hocko wrote:
Now that per-node-zone-priority iterator caches memory cgroups rather
than their css ids we have to be careful and remove them from the
iterator when they are on the way out otherwise they might hang for
unbounded amount of time
(2013/01/04 2:54), Michal Hocko wrote:
> Now that per-node-zone-priority iterator caches memory cgroups rather
> than their css ids we have to be careful and remove them from the
> iterator when they are on the way out otherwise they might hang for
> unbounded amount of time (until the
(2013/01/04 2:54), Michal Hocko wrote:
Now that per-node-zone-priority iterator caches memory cgroups rather
than their css ids we have to be careful and remove them from the
iterator when they are on the way out otherwise they might hang for
unbounded amount of time (until the global/targeted
Now that per-node-zone-priority iterator caches memory cgroups rather
than their css ids we have to be careful and remove them from the
iterator when they are on the way out otherwise they might hang for
unbounded amount of time (until the global/targeted reclaim triggers the
zone under priority
Now that per-node-zone-priority iterator caches memory cgroups rather
than their css ids we have to be careful and remove them from the
iterator when they are on the way out otherwise they might hang for
unbounded amount of time (until the global/targeted reclaim triggers the
zone under priority
60 matches
Mail list logo
