Hi Brian, > This is probably dropping into the fallback allocation algorithm in > xfs_alloc_ag_vextent_near(), explained by the following comment: > > /* > * Second algorithm. > * Search in the by-bno tree to the left and to the right > * simultaneously, until in each case we find a space big enough, > * or run into the edge of the tree. When we run into the edge, > * we deallocate that cursor. > * If both searches succeed, we compare the two spaces and pick > * the better one. > * With alignment, it's possible for both to fail; the upper > * level algorithm that picks allocation groups for allocations > * is not supposed to do this. > */ > > So what is happening here is that the algorithm is starting at a point > in an AG based on a starting blockno (e.g., such as the inode block) and > searching left and right from there for a suitable range of free blocks. > Depending on the size of the tree, fragmentation of free space, size of > the allocation request, etc., it can certainly take a while to seek/read > all of the btree blocks required to satisfy the allocation. Yes, according to my profiling, indeed all the slow allocation incidents end up in the "second" algorithm. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
