Thread (31 messages) 31 messages, 5 authors, 2012-03-01

Re: [PATCH 5/7] shrink support for memcg kmem controller

From: Glauber Costa <hidden>
Date: 2012-02-22 14:02:07
Also in: linux-mm

On 02/22/2012 03:35 AM, Suleiman Souhlal wrote:
On Tue, Feb 21, 2012 at 3:34 AM, Glauber Costa[off-list ref]  wrote:
quoted
@@ -5055,8 +5117,21 @@ int memcg_kmem_newpage(struct mem_cgroup *memcg, struct page *page, unsigned lon
  {
        unsigned long size = pages<<  PAGE_SHIFT;
        struct res_counter *fail;
+       int ret;
+       bool do_softlimit;
+
+       ret = res_counter_charge(memcg_kmem(memcg), size,&fail);
+       if (unlikely(mem_cgroup_event_ratelimit(memcg,
+                                               MEM_CGROUP_TARGET_THRESH))) {
+
+               do_softlimit = mem_cgroup_event_ratelimit(memcg,
+                                               MEM_CGROUP_TARGET_SOFTLIMIT);
+               mem_cgroup_threshold(memcg);
+               if (unlikely(do_softlimit))
+                       mem_cgroup_update_tree(memcg, page);
+       }

-       return res_counter_charge(memcg_kmem(memcg), size,&fail);
+       return ret;
  }
It seems like this might cause a lot of kernel memory allocations to
fail whenever we are at the limit, even if we have a lot of
reclaimable memory, when we don't have independent accounting.

Would it be better to use __mem_cgroup_try_charge() here, when we
don't have independent accounting, in order to deal with this
situation?
Yes, it would.
I'll work on that.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help