[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240827142613.00005c91@Huawei.com>
Date: Tue, 27 Aug 2024 14:26:13 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Ira Weiny <ira.weiny@...el.com>
CC: Dave Jiang <dave.jiang@...el.com>, Fan Ni <fan.ni@...sung.com>, "Navneet
Singh" <navneet.singh@...el.com>, Chris Mason <clm@...com>, Josef Bacik
<josef@...icpanda.com>, David Sterba <dsterba@...e.com>, Petr Mladek
<pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Rasmus Villemoes
<linux@...musvillemoes.dk>, Sergey Senozhatsky <senozhatsky@...omium.org>,
Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>, Davidlohr Bueso <dave@...olabs.net>,
Alison Schofield <alison.schofield@...el.com>, Vishal Verma
<vishal.l.verma@...el.com>, <linux-btrfs@...r.kernel.org>,
<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-doc@...r.kernel.org>, <nvdimm@...ts.linux.dev>
Subject: Re: [PATCH v3 20/25] dax/bus: Factor out dev dax resize logic
On Fri, 16 Aug 2024 09:44:28 -0500
Ira Weiny <ira.weiny@...el.com> 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@...el.com>
I'm not 100% confident on this one, so will probably take another look
before giving a tag.
One trivial comment below.
> +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 dev_size = dev_dax_size(dev_dax);
> + struct device *dev = &dev_dax->dev;
> + resource_size_t alloc = 0;
No path in which this is not set before use.
> +
> + 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;
Powered by blists - more mailing lists