diff options
author | dormando <dormando@rydia.net> | 2019-07-26 01:32:26 -0700 |
---|---|---|
committer | dormando <dormando@rydia.net> | 2019-07-26 16:26:38 -0700 |
commit | c630eeb7f4502a9d96cbec7cc9bda7ce1b1f6476 (patch) | |
tree | 3b054bd5e72b0e4da7f66455bdc01d97a9814f6b /slabs.h | |
parent | 78eb7701e0823643d693c1a7a6fd8a0c75db74d8 (diff) | |
download | memcached-c630eeb7f4502a9d96cbec7cc9bda7ce1b1f6476.tar.gz |
move mem_requested from slabs.c to items.c
mem_requested is an oddball counter: it's the total number of bytes
"actually requested" from the slab's caller. It's mainly used for a
stats counter, alerting the user that the slab factor may not be
efficient if the gap between total_chunks * chunk_size - mem_requested
is large.
However, since chunked items were added it's _also_ used to help the
LRU balance itself. The total number of bytes used in the class vs the
total number of bytes in a sub-LRU is used to judge whether to move
items between sub-LRU's.
This is a layer violation; forcing slabs.c to know more about how items
work, as well as EXTSTORE for calculating item sizes from headers.
Further, it turns out it wasn't necessary for item allocation: if we
need to evict an item we _always_ pull from COLD_LRU or force a move
from HOT_LRU. So the total doesn't matter.
The total does matter in the LRU maintainer background thread. However,
this thread caches mem_requested to avoid hitting the slab lock too
frequently. Since sizes_bytes[] within items.c is generally redundant
with mem_requested, we now total sizes_bytes[] from each sub-LRU before
starting a batch of LRU juggles.
This simplifies the code a bit, reduces the layer violations in slabs.c
slightly, and actually speeds up some hot paths as a number of branches
and operations are removed completely.
This also fixes an issue I was having with the restartable memory
branch :) recalculating p->requested and keeping a clean API is painful
and slow.
NOTE: This will vary a bit compared to what mem_requested originally
did, mostly for large chunked items.
For items which fit inside a single slab chunk, the stat is identical.
However, items constructed by chaining chunks will have a single large
"nbytes" value and end up in the highest slab class. Chunked items can
be capped with chunks from smaller slab classes; you will see
utilization of chunks but not an increase in mem_requested for them.
I'm still thinking this through but this is probably acceptable. Large
chunked items should be accounted for separately, perhaps with some new
counters so they can be discounted from normal calculations.
Diffstat (limited to 'slabs.h')
-rw-r--r-- | slabs.h | 10 |
1 files changed, 2 insertions, 8 deletions
@@ -22,20 +22,14 @@ unsigned int slabs_clsid(const size_t size); /** Allocate object of given length. 0 on error */ /*@null@*/ #define SLABS_ALLOC_NO_NEWPAGE 1 -void *slabs_alloc(const size_t size, unsigned int id, uint64_t *total_bytes, unsigned int flags); +void *slabs_alloc(const size_t size, unsigned int id, unsigned int flags); /** Free previously allocated object */ void slabs_free(void *ptr, size_t size, unsigned int id); -/** Adjust the stats for memory requested */ -void slabs_adjust_mem_requested(unsigned int id, size_t old, size_t ntotal); - /** Adjust global memory limit up or down */ bool slabs_adjust_mem_limit(size_t new_mem_limit); -/** Return a datum for stats in binary protocol */ -bool get_stats(const char *stat_type, int nkey, ADD_STAT add_stats, void *c); - typedef struct { unsigned int chunks_per_page; unsigned int chunk_size; @@ -49,7 +43,7 @@ unsigned int global_page_pool_size(bool *mem_flag); 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); +unsigned int slabs_available_chunks(unsigned int id, bool *mem_flag, unsigned int *chunks_perslab); void slabs_mlock(void); void slabs_munlock(void); |