You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Reviewed-by: Jonathan Cameron <[email protected]>
Reviewed-by: Dave Jiang <[email protected]>
Signed-off-by: Ira Weiny <[email protected]>
0 commit comments