On Mon, Mar 21, 2022 at 10:08:47PM +0800, JeffleXu wrote:
> reqs_lock is also used to protect the check of cache->flags. Please
> refer to patch 4 [1] of this patchset.
Yes, that's exactly what I meant by "bad idea".
> ```
> + /*
> + * Enqueue the pending request.
> + *
> + * Stop enqueuing the request when daemon is dying. So we need to
> + * 1) check cache state, and 2) enqueue request if cache is alive.
> + *
> + * The above two ops need to be atomic as a whole. @reqs_lock is used
> + * here to ensure that. Otherwise, request may be enqueued after xarray
> + * has been flushed, in which case the orphan request will never be
> + * completed and thus netfs will hang there forever.
> + */
> + read_lock(&cache->reqs_lock);
> +
> + /* recheck dead state under lock */
> + if (test_bit(CACHEFILES_DEAD, &cache->flags)) {
> + read_unlock(&cache->reqs_lock);
> + ret = -EIO;
> + goto out;
> + }
So this is an error path. We're almost always going to take the xa_lock
immediately after taking the read_lock. In other words, you've done two
atomic operations instead of one.
> + xa_lock(xa);
> + ret = __xa_alloc(xa, &id, req, xa_limit_32b, GFP_KERNEL);
> + if (!ret)
> + __xa_set_mark(xa, id, CACHEFILES_REQ_NEW);
> + xa_unlock(xa);
> +
> + read_unlock(&cache->reqs_lock);
> ```
>
> It's mainly used to protect against the xarray flush.
>
> Besides, IMHO read-write lock shall be more performance friendly, since
> most cases are the read side.
That's almost never true. rwlocks are usually a bad idea because you
still have to bounce the cacheline, so you replace lock contention
(which you can see) with cacheline contention (which is harder to
measure). And then you have questions about reader/writer fairness
(should new readers queue behind a writer if there's one waiting, or
should a steady stream of readers be able to hold a writer off
indefinitely?)
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs
