[PATCH v5 03/22] cachefiles: introduce on-demand read mode
Matthew Wilcox
willy at infradead.org
Tue Mar 22 02:21:10 AEDT 2022
On Mon, Mar 21, 2022 at 11:18:05PM +0800, JeffleXu wrote:
> >> 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?)
>
> Interesting, I didn't notice it before. Thanks for explaining it.
No problem. It's hard to notice.
> BTW what I want is just
>
> ```
> PROCESS 1 PROCESS 2
> ========= =========
> #lock #lock
> set DEAD state if (not DEAD)
> flush xarray enqueue into xarray
> #unlock #unlock
> ```
>
> I think it is a generic paradigm. So it seems that the spinlock inside
> xarray is already adequate for this job?
Absolutely; just use xa_lock() to protect both setting & testing the
flag.
More information about the Linux-erofs
mailing list