On 09/22/2011 12:09 PM, Balbir Singh wrote:
On Thu, Sep 22, 2011 at 11:30 AM, Greg Thelen<gthelen@xxxxxxxxxx> wrote:
On Wed, Sep 21, 2011 at 11:59 AM, Glauber Costa<glommer@xxxxxxxxxxxxx> wrote:
Right now I am working under the assumption that tasks are long lived inside
the cgroup. Migration potentially introduces some nasty locking problems in
the mem_schedule path.
Also, unless I am missing something, the memcg already has the policy of
not carrying charges around, probably because of this very same complexity.
True that at least it won't EBUSY you... But I think this is at least a way
to guarantee that the cgroup under our nose won't disappear in the middle of
our allocations.
Here's the memcg user page behavior using the same pattern:
1. user page P is allocate by task T in memcg M1
2. T is moved to memcg M2. The P charge is left behind still charged
to M1 if memory.move_charge_at_immigrate=0; or the charge is moved to
M2 if memory.move_charge_at_immigrate=1.
3. rmdir M1 will try to reclaim P (if P was left in M1). If unable to
reclaim, then P is recharged to parent(M1).
We also have some magic in page_referenced() to remove pages
referenced from different containers. What we do is try not to
penalize a cgroup if another cgroup is referencing this page and the
page under consideration is being reclaimed from the cgroup that
touched it.
Balbir Singh
humm... Then we need to keep pointers to: 1) Which allocations comes
from each socket, and 2) Which sockets comes from each task. 2 is pretty
easy, 1 may get expensive. I will investigate it now.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>