On Fri, Mar 01, 2013 at 10:14:26AM -0500, Chris Mason wrote: > On Fri, Mar 01, 2013 at 08:03:00AM -0700, David Sterba wrote: > > The stripe hash table is large, starting with allocation order 4 and can go as > > high as order 7 in case lock debugging is turned on and structure padding > > happens. > > Thanks Dave, I had this on my todo list but it dropped off. We don't > really need the stripe cache for most mounts. The code was initially > setup to only allocate it when we read a raid5/6 block group, but I ran > into trouble for the sys array. Yeah, the cmpxchg looks strange for a one-time allocation. > Still, it should really be changed to only load the cache when we hit > raid5/6 goodness. That makes sense, but even in that case I suggest to use the the vmalloc fallback. The smallest size I've calculated is ~49k and the one I'm observing with all the debugging switches turned on is 360544. The 64k kmalloc bucket has a slightly bigger chance to keep one or two entries available so we don't need vmalloc most of the time. In the remaining cases we would see spurious mount failures and this impedes automated testing. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
