lkml.org 
[lkml]   [2023]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC v2 13/18] dax/bus: Factor out dev dax resize logic
    Jonathan Cameron wrote:
    > On Mon, 28 Aug 2023 22:21:04 -0700
    > Ira Weiny <ira.weiny@intel.com> wrote:
    >
    > > Dynamic Capacity regions must limit dev dax resources to those areas
    > > which have extents backing real memory. Four alternatives were
    > > considered to manage the intersection of region space and extents:
    > >
    > > 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.
    > >
    > > 3) Maintain a separate resource tree with extents. This option is the
    > > same as 2) but with a different data structure. Most ideally we have
    > > some unified representation of the resource tree.
    > >
    > > 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.
    > >
    > > 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@intel.com>
    > Hi Ira,
    >
    > Some trivial comments on comments, but in general this indeed seems to be doing what you
    > say and factoring out the static allocation part.
    >
    > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

    Thanks!

    >
    >
    > > ---
    > > drivers/dax/bus.c | 128 +++++++++++++++++++++++++++++++++---------------------
    > > 1 file changed, 79 insertions(+), 49 deletions(-)
    > >
    > > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
    > > index b76e49813a39..ea7ae82b4687 100644
    > > --- a/drivers/dax/bus.c
    > > +++ b/drivers/dax/bus.c
    > > @@ -817,11 +817,10 @@ static int devm_register_dax_mapping(struct dev_dax *dev_dax, int range_id)
    > > return 0;
    > > }
    > >
    >
    > > -static ssize_t dev_dax_resize(struct dax_region *dax_region,
    > > - struct dev_dax *dev_dax, resource_size_t size)
    > > +/*
    >
    > /**
    >
    > Suitable builds will then check this doc matches the function etc
    > even if this is never included into any of the docs build.

    Done.

    >
    > > + * dev_dax_resize_static - Expand the device into the unused portion of the
    > > + * region. This may involve adjusting the end of an existing resource, or
    > > + * allocating a new resource.
    > > + *
    > > + * @parent: parent resource to allocate this range in.
    > > + * @dev_dax: DAX device we are creating this range for
    >
    > Trivial: Doesn't seem to be consistent on . or not

    That is because my brain has a real consistency issue on this... ;-)

    '.' removed.

    Thanks again,
    Ira

    \
     
     \ /
      Last update: 2023-09-06 06:14    [W:4.090 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site