On Thu, Aug 04, 2016 at 09:00:07AM -0700, Christoph Hellwig wrote: > On Thu, Aug 04, 2016 at 08:57:56AM +1000, Dave Chinner wrote: > > So, please explain in more detail what the problem is and what the > > proposed solution is so I (and probably Darrick, too) have some > > understanding of the issue you see with this code. > > We were doing 1 (actually 2 with the busy extent tracking) allocations > for each free extent, and now we're up to three. We need to get this > down to 1 and not increase it for no benefit. Oh, it's memory allocations in the extent freeing path you're worried about? That's a minor concern at this point, really. We do some many other allocations in these paths (e.g. multiple allocations for every metadata buffer that is not in cache) that another is not going to make any difference to the system stability or performance. Yes, it would be good to reduce the number of allocations, but it's not critical to the correct functioning of the code. hence it doesn't need to be solved right now, and We can work on optimising this over the next few months as we clean up all the rough edges we find. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
