Re: Source code, lru_lock vs former cache_lock

2023-02-27 Thread dormando
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(_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(_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.


Source code, lru_lock vs former cache_lock

2023-02-27 Thread Slawomir Pryczek
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(_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(_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.