On Wed, Jan 26, 2011 at 03:22:48PM -0600, Alex Elder wrote: > On Tue, 2011-01-25 at 19:50 +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Delayed allocation extents can be larger than AGs, so when trying to > > convert a large range we may scan every AG inside > > xfs_bmap_alloc_nullfb() trying to find an AG with a size larger than > > an AG. We should stop when we find the first AG with a maximum > > possible allocation size. This causes excessive CPU usage when there > > are lots of AGs. > > > > The same problem occurs when doing preallocation of a range larger > > than an AG. > > > > Fix the problem by limiting real allocation lengths to the maximum > > that an AG can support. This means if we have empty AGs, we'll stop > > the search at the first of them. If there are no empty AGs, we'll > > still scan them all, but that is a different problem.... > > Maybe I'm wrong but I think you need to change a "+" > to a "-" (shown below). Good catch. That's what I get for cleaning up code ;) > > And I have a few really minor suggestions: > - You should update a comment (which I point > out below) to match your change. Will fix. > - Maybe make use of a local variable, at least > in xfs_bmap_btalloc_nullfb(), such as: > xfs_extlen_t requested = args->maxlen; All the allocation code is coded that way to avoid putting local variables on the stack. The allocation-in-writeback path is the critical stack usage path in XFS, so I'd prefer to keep using args->maxlen here.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
