I want your opinion guys regarding two features implemented in attempt to
greatly reduce number of memory allocation without major surgery in the
code.
The features are:
1. Custom STL allocator, which allocates first N items from the STL
container itself. This is semi-transparent replacement of standard
allocator. Just need to replace std::map with ceph_map for example.
Limitation: a) Brakes move semantic. b) No deallocation implemented, so no
good for big long living containers.
2. Placement allocator, which allows chained allocation of shorter living
object from longer living. Example would be allocation of finish contexts
from aio completion context.
Limitation: a) May require some code rearrangement in order to avoid
concurrent deallocations, otherwise deallocation code uses synchronization
what limits performance. b) same as above b)
Performance results for 32 threads in a synthetic test, std allocator time
to custom
allocator time ratio:
stlalloc stl+placement alloc
block jemalloc tcmalloc ptmalloc jemalloc tcmalloc ptmalloc
1M 1298.01 650.66 137.64 735.49 824.45 9.62
64K 514.84 2.82 304.62 570.74 4.85 12.21
32K 838.89 2.17 5.03 1600.5 7.43 8.28
4K 2.76 1.99 4.98 4.36 5.3 8.23
32B 2.67 5.09 3.69 4.41 8.48 6.4
(100M test iterations for 32B and 4K, 2M for 32K and 64K, 200K for 1M)
I didn¹t see any performance improvement in 100% write fio test, it still
can shine in other workloads or proper classes replaced.
Let me know if it worth to PR them.
STL allocator:
https://github.com/efirs/ceph/commit/4eed0d63dbcbd00ee3aa325355bfbe56acbb7b
05
STL allocator usage example:
https://github.com/efirs/ceph/commit/362c5c4e10563785cc89370d28511e0493f1b2
11
https://github.com/efirs/ceph/commit/e2df67f7570c68e53775bc55cda12c6253e66d
2f
Placement allocator:
https://github.com/efirs/ceph/commit/8df5cd7d753fd09e79a24f2fc781cf3af02e6d
3e
Placement allocator usage example:
https://github.com/efirs/ceph/commit/70db18d9c1b39190bde68548b57c2aa7a9e455
e0
‹
Evgeniy
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
