On Mon, 07 Oct 2024 18:16:29 -0500
Ira Weiny <ira.weiny@xxxxxxxxx> wrote:
> Dynamic Capacity regions must limit dev dax resources to those areas
> which have extents backing real memory. Such DAX regions are dubbed
> 'sparse' regions. In order to manage where memory is available four
> alternatives were considered:
>
> 1) Create a single region resource child on region creation which
> reserves the entire region. Then as extents are added punch holes in
> this reservation. This requires new resource manipulation to punch
> the holes and still requires an additional iteration over the extent
> areas which may already have existing dev dax resources used.
>
> 2) Maintain an ordered xarray of extents which can be queried while
> processing the resize logic. The issue is that existing region->res
> children may artificially limit the allocation size sent to
> alloc_dev_dax_range(). IE the resource children can't be directly
> used in the resize logic to find where space in the region is. This
> also poses a problem of managing the available size in 2 places.
>
> 3) Maintain a separate resource tree with extents. This option is the
> same as 2) but with the different data structure. Most ideally there
> should be a unified representation of the resource tree not two places
> to look for space.
>
> 4) Create region resource children for each extent. Manage the dax dev
> resize logic in the same way as before but use a region child
> (extent) resource as the parents to find space within each extent.
>
> Option 4 can leverage the existing resize algorithm to find space within
> the extents. It manages the available space in a singular resource tree
> which is less complicated for finding space.
>
> In preparation for this change, factor out the dev_dax_resize logic.
> For static regions use dax_region->res as the parent to find space for
> the dax ranges. Future patches will use the same algorithm with
> individual extent resources as the parent.
>
> Signed-off-by: Ira Weiny <ira.weiny@xxxxxxxxx>
> ---
> Changes:
> [Jonathan: Fix handling of alloc]
Trivial comments inline.
Not an area I know much about, so treat this one as a 'smells ok'
type of tag.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> +
> +static ssize_t dev_dax_resize(struct dax_region *dax_region,
> + struct dev_dax *dev_dax, resource_size_t size)
> +{
> + resource_size_t avail = dax_region_avail_size(dax_region), to_alloc;
resource_size_t to_alloc;
on it's own line. That was hard to spot all the way over there.
Obviously this was in original code, but maybe slip a tidy up in whilst
you are moving it?
> + resource_size_t dev_size = dev_dax_size(dev_dax);
> + struct device *dev = &dev_dax->dev;
> + resource_size_t alloc;
> +
> + if (dev->driver)
> + return -EBUSY;
> + if (size == dev_size)
> + return 0;
> + if (size > dev_size && size - dev_size > avail)
> + return -ENOSPC;
> + if (size < dev_size)
> + return dev_dax_shrink(dev_dax, size);
> +
> + to_alloc = size - dev_size;
> + if (dev_WARN_ONCE(dev, !alloc_is_aligned(dev_dax, to_alloc),
> + "resize of %pa misaligned\n", &to_alloc))
> + return -ENXIO;
> +
> +retry:
> + alloc = dev_dax_resize_static(&dax_region->res, dev_dax, to_alloc);
> + if (alloc <= 0)
> + return alloc;
> to_alloc -= alloc;
> if (to_alloc)
> goto retry;
