Hey,
That old "item_cachedump" command is deprecated. The locking is fine; it's
actually only looking at the COLD_LRU instead of walking all of them like
the lru_crawler.
I'd rather remove the command entirely than do any further work on it; it
has a hard limit on how many keys it can dump, it locks up the whole
worker thread while it fills the buffer, etc. The lru_crawler is superior
in all ways.
On Mon, 27 Feb 2023, Slawomir Pryczek wrote:
> Hi, I was reading about LRU lock a bit and have a question regarding
> item_cachedump
> unsigned int id = slabs_clsid;
> id |= COLD_LRU;
> pthread_mutex_lock(&lru_locks[id]);
>
> 1. Why in this code we're binary adding COLD_LRU, while for example in
> lru_crawler's code we're just using slab class IDs. This way other threads are
> able to access locked resources, is that correct?
>
> 2.
> pthread_mutex_lock(&lru_locks[slab_class_id]);
> uint32_t hv = hash(ITEM_key(it), it->nkey);
> void *hold_lock = NULL;
> if ((hold_lock = item_trylock(hv)) == NULL) {
> continue;
> }
> if (refcount_incr(it) == 2) {
> // LOCKED
>
> Is it still correct way to lock an item so it can be safely read?
>
> 3. for the item_cachedump I found this comment
>
> /* This is walking the line of violating lock order, but I think it's safe.
> * If the LRU lock is held, an item in the LRU cannot be wiped and freed.
> * The data could possibly be overwritten, but this is only accessing the
> * headers.
> * It may not be the best idea to leave it like this, but for now it's safe.
> */
>
> Why it may violate lock order when we have only single lock acquired in this
> function? IS there some doc about correct (updated) lock order, the one in
> sources seems outdated...
>
> Thanks,
> Slawomir.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to memcached+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/e19afc89-ccc1-4410-b6cf-3b005529df4an%40googlegroups.com.
>
>
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/memcached/1fdc16a1-afe9-bc18-24bc-bc7e56aa86%40rydia.net.
