(2012/08/18 7:03), Ying Han wrote:

On Mon, Aug 6, 2012 at 6:33 AM, Michal Hocko [off-list ref] wrote:

quoted

On Fri 03-08-12 09:34:11, Ying Han wrote:

quoted

On Fri, Aug 3, 2012 at 9:16 AM, Rik van Riel [off-list ref] wrote:

quoted

On 08/03/2012 11:22 AM, Michal Hocko wrote:

quoted

On Thu 02-08-12 14:24:18, Ying Han wrote:

I am thinking that we could add a constant for the priority
limit. Something like
#define MEMCG_LOW_SOFTLIMIT_PRIORITY    DEF_PRIORITY

Although it doesn't seem necessary at the moment, because there is just
one location where it matters but it could help in the future.
What do you think?

I am working on changing the code to find the "highest priority"
LRU and reclaim from that list first.  That will obviate the need
for such a change. However, the other cleanups and simplifications
made by Ying's patch are good to have...

So what you guys think to take from here. I can make the change as
Michal suggested if that would be something helpful future changes.
However, I wonder whether or not it is necessary.

I am afraid we will not move forward without a proper implementation of
the "nobody under soft limit" case. Maybe Rik's idea would just work out
but this patch on it's own could regress so taking it separately is no
go IMO. I like how it reduces the code size but we are not "there" yet...

Sorry for getting back to the thread late. Being distracted to
something else which of course happens all the time.

Before me jumping into actions of any changes, let me clarify the
problem I am facing:

All the concerns are related to the configuration where none of the
memcg is eligible for reclaim ( usage < softlimit ) under global
pressure.   The current code works like the following:

1. walk the memcg tree and for each checks the softlimit
2. if none of the memcg is being reclaimed, then set the ignore_softlimit
3. restart the walk and this round forget about the softlimit

There are two problems I heard here:
1. doing a full walk on step 1 would cause potential scalability issue.

Simply thinking, I think maintaining & updating the whole softlimit information
periodically is a way to avoid double-scan. memcg has a percpu event-counter and
css-id bitmap will be enough for keeping information. Then, you can find
over-softlimit memcg by bitmap scanning.

2. root cgroup is a exception where it always eligible for reclaim (
softlimit = 0 always). That will cause root to be punished more than
necessary.

When use_hierarchy==0 ?
How about having implicit softlimit value for root, which is automatically
calculated from total_ram or the number of tasks in root ?

Thanks,
-Kame






--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>