summaryrefslogtreecommitdiff
path: root/slabs.h
diff options
context:
space:
mode:
authordormando <dormando@rydia.net>2019-07-26 01:32:26 -0700
committerdormando <dormando@rydia.net>2019-07-26 16:26:38 -0700
commitc630eeb7f4502a9d96cbec7cc9bda7ce1b1f6476 (patch)
tree3b054bd5e72b0e4da7f66455bdc01d97a9814f6b /slabs.h
parent78eb7701e0823643d693c1a7a6fd8a0c75db74d8 (diff)
downloadmemcached-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.h10
1 files changed, 2 insertions, 8 deletions
diff --git a/slabs.h b/slabs.h
index 1516f86..abb4b89 100644
--- a/slabs.h
+++ b/slabs.h
@@ -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);