Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 22 Mar 2022 10:22:50 -0700 | Subject | Re: [GIT PULL] f2fs for 5.18 |
| |
On Mon, Mar 21, 2022 at 1:39 PM Jaegeuk Kim <jaegeuk@kernel.org> 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.
The whole notion of making an rwsem unfair to readers sounds really really odd. I mean, the whole and only _point_ of an rwsem is to allow concurrent readers, and traditionally if it's unfair it's unfair to _writers_ because that tends to be better for throughput (but unfairness can cause horrible latency).
So it smells like there's something bad going on in f2fs.
That said, I'm adding Waiman to the cc here in case he would have ideas at least for a cleaner interface. Our rw_semaphores are explicitly trying to be fair, because unfairness (the other way) was such a big problem.
I'm wondering it the optimistic read lock stealing is bothering f2fs?
Linus
| |