Messages in this thread | | | Date | Thu, 20 Oct 2022 13:02:07 -0700 | From | Yury Norov <> | Subject | Re: [RFC PATCH 0/2] Switch ARM to generic find_bit() API |
| |
On Thu, Oct 20, 2022 at 05:51:34PM +0100, Russell King (Oracle) wrote: > On Wed, Oct 19, 2022 at 08:20:22PM -0700, Yury Norov wrote: > > Hi Russell, all, > > > > I'd like to respin a patch that switches ARM to generic find_bit() > > functions. > > > > Generic code works on par with arch or better, according to my > > testing [1], and with recent improvements merged in v6.1, it should > > be even faster. > > > > ARM already uses many generic find_bit() functions - those that it > > doesn't implement. So we are talking about migrating a subset of the > > API; most of find_bit() family has only generic implementation on ARM. > > > > The only concern about this migration is that ARM code supports > > byte-aligned bitmap addresses, while generic code is optimized for > > word-aligned bitmaps. > > > > In my practice, I've never seen unaligned bitmaps. But to check that on > > ARM, I added a run-time check for bitmap alignment. I gave it run on > > several architectures and found nothing. > > > > Can you please check that on your hardware and compare performance of > > generic vs arch code for you? If everything is OK, I suggest switching > > ARM to generic find_bit() completely. > > > > Thanks, > > Yury > > > > [1] https://lore.kernel.org/all/YuWk3titnOiQACzC@yury-laptop/ > > I _really_ don't want to play around with this stuff right now... 6.0 > appears to have a regression on arm32 early on during boot: > > [ 1.410115] EXT4-fs error (device sda1): htree_dirblock_to_tree:1093: inode #256: block 8797: comm systemd: bad entry in directory: rec_len % 4 != 0 - offset=0, inode=33188, rec_len=35097, size=4096 fake=0 > > Booting 5.19 with the same filesystem works without issue and without > even a fsck, but booting 6.0 always results in some problem that > prevents it booting. > > Debugging this is not easy, because there also seems to be something > up with the bloody serial console - sometimes I get nothing, other > times I get nothing more than: > > [ 2.929502] EXT4-fs error (de > > and then the output stops. Is the console no longer synchronous? If it > isn't, that's a huge mistake which can be seen right here with the > partial message output... so I also need to work out how to make the > console output synchronous again.
Got it.
I you think that EXT4 problems are due to unaligned bitmaps, you can take 1st patch from this series to check.
Thanks, Yury
| |