Christoph Lameter wrote:
On Thu, 10 Aug 2006, KAMEZAWA Hiroyuki wrote:
BTW, in recent Linux, many objects are freed by call_rcu(hoo, dealyed_free_foo).
Objects are freed far after it was touched.
I think catching this kind of freeing will not boost performance by cache-hit if
reuse freed page (object).
Yes that is a general problem with RCU freeing. One can use the
SLAB_DESTROY_BY_RCU option to have RCU applied to the whole slab. In that
case on can use the cache hot effect but has the additional problem in RCU
of dealing with the issue that the object can be replaced at any time.
No SLAB_DESTROY_BY_RCU is not equivalent to delayed_free_foo().
SLAB_DESTROY_BY_RCU just means that the slab allocator uses
delayed_free_pages() instead of free_pages().
kmem_cache_free() does not delay the reuse, an object will be returned
by the next kmem_cache_alloc, without any grace periods in between.
Independantly from that point, we need some benchmarks to test the
allocator.
The last benchmarks of the slab allocator (that I'm aware of) were done
with packet routing - packet routing was the reason why the shared_array
layer was added:
The shared_array layer is used to perform inter-cpu bulk object
transfers. Without that cache, i.e. if a list_add() / list_del() was
required to transfer one object from one cpu to another cpu, a
significant amount of time was spent in the allocator.
Christoph, could you run a test? GigE routing with tiny packets should
be sufficient. Two cpu bound nics, one does rx, the other one tx. Move
the skb_head_cache to sslab.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
