On Tue, Jan 02, 2024 at 11:37:41PM -0800, Christoph Hellwig wrote: > On Tue, Jan 02, 2024 at 05:07:47PM -0800, Darrick J. Wong wrote: > > The main arches that xfs really cares about are arm64, ppc64, riscv, > > s390x, and x86_64, right? Perhaps there's a stronger case for only > > providing blocking notifiers and jump labels since there aren't many > > m68k xfs users, right? > > Yes. And if there are m68k xfs users, they are even more unlikely to run > with online repair enabled as they'd be very memory constrained. > > So I suspect always using blocking notifiers would be best to keep > the complexity down. In fact I suspect we should simply make online > repair depend on jump labels instead of selecting it when available > to remove anoher rarely tested build combination. Later on in the online fsck patch series, scrub will start using LIVE_HOOKS for some of its scanning functionality. I don't know that anyone will really want to use online fsck on weird old systems like you said, but while it's EXPERIMENTAL I don't want to lose the option entirely. That said, static branches do have a fallback for !HAVE_ARCH_JUMP_LABEL case, which is raw_atomic_read. I'll get rid of the srcu notifier chain xfs_hook implementation to reduce the complexity within xfs. Online fsck will always use static branches + blocking rwsem notifiers. For modern arches like x64 there will be almost zero runtime cost due to the nop sled. For m68k and friends, they can kick the tires on xfs_scrub, but if the performance sucks due to the READ_ONCE then oh well. --D
