Re: [Lse-tech] Re: Skb initialization patch

[David S. Miller]

   From: "Mala Anand" <[e-mail]>
   Date: Wed, 16 Oct 2002 18:20:48 -0500

   Are you saying that the skbs do not migrate between the per cpu
   pools (hotlist) if you have enough skbs in the hotlist/slab cache.
   There is always going to be migration of objects between CPUs
   even if you have enough objects per cpu pool.  There are other
   elements come into picture such as memory reclaim etc.,
   Moreover there is no guarantee that once a skb is allocated from
   cpu 0 pool, it would be freed to cpu 0 pool.
   
Your original claim was that moving the initialization from "free
time" to "alloc time" reduces inter-cpu cache activity.

You are arguing now that, after allocation, the object can move from
one cpu to another.

This new argument is incompatible with the argument that touching
the dirty data at "alloc time" improves performance, in fact it
should reduce performance in some cases.

   If the per cpu SLAB pool is depleted, it goes to the general
   slab pool. As I pointed out earlier you cannot eliminate this
   completely.
   
No, but you can make it happen much less often.  I really believe
the effort belongs here, because it helps everyone using SLAB
with constructors.

If the SLAB problem is "unsolvable", then we should just kill
constructor/destructor facility of SLAB because, as per your
arguments, it deteriorates performance on SMP if actually used.

   BTW SLAB is where I started the investigation, I will go back
   to that later. We can modify SLAB cache to hold more objects
   per cpu, but that won't eliminate the migration of objects.
   
And I argue that your patch cannot improve locality for the bad
inter-cpu SKB movement cases which occur post-allocation.

   I am working on the problem I posted yesterday. This skb init patch
   was done long time ago. I just collected data on new kernels.
   
Hmmm, you said data was with 2.5.38 kernel.  Were these SKB init tests
done with something more recent?