Re: [PATCH 12/30] mm: memory reserve management

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Pekka Enberg <penberg@...>
Cc: Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>, <linux-kernel@...>, <linux-mm@...>, <netdev@...>, <trond.myklebust@...>, Daniel Lezcano <dlezcano@...>, Neil Brown <neilb@...>, <mpm@...>, <cl@...>
Date: Monday, July 28, 2008 - 6:17 am

On Mon, 2008-07-28 at 13:06 +0300, Pekka Enberg wrote:

See below..


Yes, my latest does have those.. let me paste the relevant bit:

+void *___kmalloc_reserve(size_t size, gfp_t flags, int node, void *ip,
+                        struct mem_reserve *res, int *emerg)
+{
+       void *obj;
+       gfp_t gfp;
+
+       /*
+        * Try a regular allocation, when that fails and we're not entitled
+        * to the reserves, fail.
+        */
+       gfp = flags | __GFP_NOMEMALLOC | __GFP_NOWARN;
+       obj = __kmalloc_node_track_caller(size, gfp, node, ip);
+
+       if (obj || !(gfp_to_alloc_flags(flags) & ALLOC_NO_WATERMARKS))
+               goto out;
+
+       /*
+        * If we were given a reserve to charge against, try that.
+        */
+       if (res && !mem_reserve_kmalloc_charge(res, size)) {
+               /*
+                * If we failed to charge and we're not allowed to wait for
+                * it to succeed, bail.
+                */
+               if (!(flags & __GFP_WAIT))
+                       goto out;
+
+               /*
+                * Wait for a successfull charge against the reserve. All
+                * uncharge operations against this reserve will wake us up.
+                */
+               wait_event(res->waitqueue,
+                               mem_reserve_kmalloc_charge(res, size));
+
+               /*
+                * After waiting for it, again try a regular allocation.
+                * Pressure could have lifted during our sleep. If this
+                * succeeds, uncharge the reserve.
+                */
+               obj = __kmalloc_node_track_caller(size, gfp, node, ip);
+               if (obj) {
+                       mem_reserve_kmalloc_charge(res, -size);
+                       goto out;
+               }
+       }
+
+       /*
+        * Regular allocation failed, and we've successfully charged our
+        * requested usage against the reserve. Do the emergency allocation.
+        */
+       obj = __kmalloc_node_track_caller(size, flags, node, ip);
+       WARN_ON(!obj);
+       if (emerg)
+               *emerg |= 1;
+
+out:
+       return obj;
+}



because a regular allocation succeeded.


Note the different allocation flags for the two allocations.


Well, this allocation should never fail:
  - we reserved memory
  - we accounted/throttle its usage

Thus this allocation should always succeed.


Patch 19/30 has:

-       data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info),
-                       gfp_mask, node);
+       data = kmalloc_reserve(size + sizeof(struct skb_shared_info),
+                       gfp_mask, node, &net_skb_reserve, &emergency);
        if (!data)
                goto nodata;

@@ -205,6 +211,7 @@ struct sk_buff *__alloc_skb(unsigned int
         * the tail pointer in struct sk_buff!
         */
        memset(skb, 0, offsetof(struct sk_buff, tail));
+       skb->emergency = emergency;
        skb->truesize = size + sizeof(struct sk_buff);
        atomic_set(&skb->users, 1);
        skb->head = data;



My issue with moving these helpers into mm/sl?b.c is that it would
require replicating all this code 3 times. Even though the functionality
is (or should) be invariant to the actual slab implementation.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 12/30] mm: memory reserve management, Peter Zijlstra, (Thu Jul 24, 10:00 am)
Re: [PATCH 12/30] mm: memory reserve management, Pekka Enberg, (Mon Jul 28, 6:06 am)
Re: [PATCH 12/30] mm: memory reserve management, Matt Mackall, (Mon Jul 28, 12:49 pm)
Re: [PATCH 12/30] mm: memory reserve management, Peter Zijlstra, (Mon Jul 28, 1:13 pm)
Re: [PATCH 12/30] mm: memory reserve management, Peter Zijlstra, (Mon Jul 28, 6:17 am)
Re: [PATCH 12/30] mm: memory reserve management, Pekka Enberg, (Mon Jul 28, 6:29 am)
Re: [PATCH 12/30] mm: memory reserve management, Peter Zijlstra, (Mon Jul 28, 6:39 am)
Re: [PATCH 12/30] mm: memory reserve management, Matt Mackall, (Mon Jul 28, 12:59 pm)
Re: [PATCH 12/30] mm: memory reserve management, Peter Zijlstra, (Mon Jul 28, 1:13 pm)
Re: [PATCH 12/30] mm: memory reserve management, Pekka Enberg, (Mon Jul 28, 6:41 am)