Jan Kara wrote: >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Jan Kara wrote: >> >> >>> Hi, >>> >>> just one note: I've looked to the in scan_bitmap() in bitmap.c. There is: >>> /* When the bitmap is more than 10% free, anyone can allocate. >>> * When it's less than 10% free, only files that already use the >>> * bitmap are allowed. Once we pass 80% full, this restriction >>> * is lifted. >>> * >>> * We do this so that files that grow later still have space >>> * close to >>> * their original allocation. This improves locality, and >>> * presumably >>> * performance as a result. >>> * >>> * This is only an allocation policy and does not make up for >>> * getting a >>> * bad hint. Decent hinting must be implemented for this to work >>> * well. >>> */ >>> if (TEST_OPTION(skip_busy, s) >>> && SB_FREE_BLOCKS(s) > SB_BLOCK_COUNT(s) / 20) { >>> >>> How about eliminating this feature entirely. It seems rather dubious.
>>> So the comment suggests we should lift the restriction when we are 80% >>>full but if you see the condition, it checks wherher we are 95% full! I >>>guess that is really asking for trouble and could explain the >>>behaviour... >>> Mike could you try changing that 20 in the test to 5? IMHO that could >>>fix your problem. >>> >>> >>Shoot. I guess I never sent that mail out last night. I had discovered >>the same thing. The thing is, I don't think it will cause the kind of >>performance problem we're seeing here. Once it sees the 90% check it >>will bail out. Minor slowdown, not anything like we're seeing. >> >> > Hmm, right. You'll only scan that one bitmap the file is in, won't > > I don't understand your remark. These files are in many many bitmaps.... Can you quote more of the code? >you? That can still take some time so maybe it's worth trying this fix >anyway. > > Honza > >