diff options
author | dormando <dormando@rydia.net> | 2017-02-22 19:32:50 -0800 |
---|---|---|
committer | dormando <dormando@rydia.net> | 2017-03-19 18:32:33 -0700 |
commit | ae84d771811394a9f6f2ff12022707f69bdc311f (patch) | |
tree | c84a692064c2604be72c097072afd4f6d53f4762 /slabs.h | |
parent | 2f9f51d48af688b1283a235de9d918963666e166 (diff) | |
download | memcached-ae84d771811394a9f6f2ff12022707f69bdc311f.tar.gz |
refactor chunk chaining for memory efficiency1.4.36
Memory chunk chains would simply stitch multiple chunks of the highest slab
class together. If your item was 17k and the chunk limit is 16k, the item
would use 32k of space instead of a bit over 17k.
This refactor simplifies the slab allocation path and pulls the allocation of
chunks into the upload process. A "large" item gets a small chunk assigned as
an object header, rather than attempting to inline a slab chunk into a parent
chunk. It then gets chunks individually allocated and added into the chain
while the object uploads.
This solves a lot of issues:
1) When assembling new, potentially very large items, we don't have to sit and
spin evicting objects all at once. If there are 20 16k chunks in the tail and
we allocate a 1 meg item, the new item will evict one of those chunks
inbetween each read, rather than trying to guess how many loops to run before
giving up. Very large objects take time to read from the socket anyway.
2) Simplifies code around the initial chunk. Originally embedding data into
the top chunk and embedding data at the same time required a good amount of
fiddling. (Though this might flip back to embedding the initial chunk if I can
clean it up a bit more).
3) Pulling chunks individually means the slabber code can be flatened to not
think about chunks aside from freeing them, which culled a lot of code and
removed branches from a hot path.
4) The size of the final chunk is naturally set to the remaining about of
bytes that need to be stored, which means chunks from another slab class can
be pulled to "cap off" a large item, reducing memory overhead.
Diffstat (limited to 'slabs.h')
-rw-r--r-- | slabs.h | 3 |
1 files changed, 3 insertions, 0 deletions
@@ -40,6 +40,9 @@ void slabs_stats(ADD_STAT add_stats, void *c); /* Hints as to freespace in slab class */ unsigned int slabs_available_chunks(unsigned int id, bool *mem_flag, uint64_t *total_bytes, unsigned int *chunks_perslab); +void slabs_mlock(void); +void slabs_munlock(void); + int start_slab_maintenance_thread(void); void stop_slab_maintenance_thread(void); |