Re: [GIT PULL] f2fs for 5.18

[Waiman Long]

On 3/23/22 12:48, Jaegeuk Kim wrote:
> On 03/23, Christoph Hellwig wrote:
> > On Tue, Mar 22, 2022 at 10:22:50AM -0700, Linus Torvalds wrote:
> > > On Mon, Mar 21, 2022 at 1:39 PM Jaegeuk Kim <jaegeuk@xxxxxxxxxx> wrote:
> > > > In this cycle, f2fs has some performance improvements for Android workloads such
> > > > as using read-unfair rwsems [...]
> > > I've pulled this, but that read-unfair rwsem code looks incredibly
> > > dodgy. Doing your own locking is always a bad sign, and it ahs
> > > traditionally come back to bite us pretty much every time. At least it
> > > uses real lock primitives, just in a really odd way.
> > FYI, Peter and I both pointed this out when the patches were posted
> > and NAKed the patch, but the feedback was ignored.
> Christoph, I proposed,
>
> "I've been waiting for a generic solution as suggested here. Until then, I'd like
> to keep this in f2fs *only* in order to ship the fix in products. Once there's
> a right fix, let me drop or revise this patch again."
>
> https://lore.kernel.org/linux-f2fs-devel/YhZzV11+BlgI1PBd@xxxxxxxxxx/
I suspect f2fs may also need the 617f3ef95177 ("locking/rwsem: Remove 
reader optimistic spinning") to give higher priority to writer. Please 
let me know the test result when you are able to test v5.15 LTS to see 
if these commits are able to address the f2fs issue.

I have some ideas of making a reader-unfair rwsem, but that requires 
either the introduction of a set of new down_read() variants or keeping 
the unfair state in the rwsem itself. I would like to make sure that 
there is really a need for such a thing before working on it.

Cheers,
Longman