On Wed, Aug 21, 2019 at 02:44:13AM +0200, hch@xxxxxx wrote: > On Wed, Aug 21, 2019 at 10:26:43AM +1000, Dave Chinner wrote: > > After thinking on this for a bit, I suspect the better thing to do > > here is add a KM_ALIGNED flag to the allocation, so if the internal > > kmem_alloc() returns an unaligned pointer we free it and fall > > through to vmalloc() to get a properly aligned pointer.... > > > > That way none of the other interfaces have to change, and we can > > then use kmem_alloc_large() everywhere we allocate buffers for IO. > > And we don't need new infrastructure just to support these debug > > configurations, either. > > > > Actually, kmem_alloc_io() might be a better idea - keep the aligned > > flag internal to the kmem code. Seems like a pretty simple solution > > to the entire problem we have here... > > The interface sounds ok. The simple try and fallback implementation > OTOH means we always do two allocations іf slub debugging is enabled, > which is a little lasty. Some creative ifdefery could avoid that, but quite frankly it's only necessary for limited allocation contexts and so the overhead/interactions would largely be unnoticable compared to the wider impact of memory debugging... > I guess the best we can do for 5.3 and > then figure out a way to avoid for later. Yeah, it also has the advantage of documenting all the places we need to be careful of allocation alignment, and it would allow us to simply plug in whatever future infrastructure comes along that guarantees allocation alignment without changing any other XFS code... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
