Received: by 2002:a05:7208:d0c6:b0:81:def:69cd with SMTP id w6csp1330rba; Sun, 24 Mar 2024 20:55:11 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVZdLf5zTFvRakfV3nvtUi6+pcJXw+o/PtuPJkpzoJO6AfQ1C+HxfavTaZAMYYEOJYJKNpMhRD/R1ser+LxGhMCRfOPJqrNg63TGYEvBA== X-Google-Smtp-Source: AGHT+IFS86LUxyEtO9k3IwoHmLpG8mzv1Uf/nn7oFSi5ZTyTlvFg9DpVTGmOSRoAgncdIP0F4y+O X-Received: by 2002:a05:6214:2406:b0:696:4c42:e66a with SMTP id fv6-20020a056214240600b006964c42e66amr7799359qvb.23.1711338911654; Sun, 24 Mar 2024 20:55:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711338911; cv=pass; d=google.com; s=arc-20160816; b=ZZLycYhWw1nk8a0uPZfOwNegYotCIMIDxUq0lQPaFfB6Lb2iIn+edGyyXjxovVkA+L +uY2DAS9PqqptAzc22rNRBE538mMUSRTM4VbJPAeB7Q1nvodgHFVODVxKCNY4H06ubhn QXE0T0aFy7ylslOcZ0EarxQWc8NIElvY/nforVwlo+XAhfgU3jZsQs/oVWK7RcBROnfL fRsrs+T+RAu8FkF72JHZA18QKr5awVcfRsmvy9ghXMc/1uIyBuj5yD7k9bQ9SEB9ra5o tc4Na4kAMKKt1OPdVPuiYxFZY/r+U/A7MU0MH+6nvywuqWHsGUhvtQMjCEVRPwhPRYV0 A6Cg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=hMmIR39fuAOBkkxkNQgGa1LgjAKK61RmsOK97Z3Wh+c=; fh=jwXaZJRrOM4egV/vk4EDc5NAOlRIQo+IhUtiKaNRnyo=; b=ijhW9Yri7AO8P8baC7Bgs/UtY/mexKWsRE3y02Ze4wXbtdkR9LPb57fgXxX+BC6doq KO0REqbiOasf0cqu8bH0H9sbNQdOolpc2UF8/jjGMW63q5nz6B2kLVVPNpnFJw/qAr3Q MBQMIBS8P0IhabtRC4vwelkYEuXlq4L1/qmzM59iILiMjvcx98hWu37pGIyHT802xhQj /XYLsbkEn+awQr43z+FqeZuslu9M/8fzH4sQfwHwtfo9ftgAR8EOnTP2qH31E7B81EHM KJU7h5I3KVWQ++OkHvQlKfYsm4Tc8bRd2zI07vuaowGwU4QnTXIU7uDe8OTygVsHXenD jfaA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=LD+Rah4x; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-114664-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-114664-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id o5-20020ad45c85000000b0069691a54db9si589485qvh.595.2024.03.24.20.55.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Mar 2024 20:55:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-114664-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=LD+Rah4x; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-114664-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-114664-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 549581C297D2 for ; Mon, 25 Mar 2024 03:55:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A63C82B0A8D; Sun, 24 Mar 2024 23:58:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="LD+Rah4x" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D9CA236D1B; Sun, 24 Mar 2024 23:18:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711322310; cv=none; b=iwbUOGHwJhr2khMhUe3ipanPnUyhPTvCYbzTEFWLEEolNSCOb6Ex1oOGdl7wZq+IZYmRz7X/mPB4Je9fOb+EVt13L7N5jsa4f7QV7f9jowACA/2XNswgkxk03GizFwgNAtX73p4b2oBAvZoG2BOvB+8Tnfpvn0S7eGnHZAH8DFs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711322310; c=relaxed/simple; bh=ut6MPUSgbN0WUhXp23QFP+26uxY7Nhx7fWMd5btbDxw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=H6jnqQYegNWku6ABmzibIR3mBmlFCT35nSESGhiIh5dvJVhWF/hfJjq1JN4RZdXQgnXKFe+G28MM7ZBdiV2fLfkDiyj+rCl2Eu5i5uAWE8r4T704CToVHIY+clFbd2dwP5ak3bVgqFKsopGeU4npaN8lEDXlHb0lkIyd4pNU8K0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=LD+Rah4x; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711322308; x=1742858308; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=ut6MPUSgbN0WUhXp23QFP+26uxY7Nhx7fWMd5btbDxw=; b=LD+Rah4xKdomjyrxiEF0j7m1QVD3U3uS2R+kROiC/eHTzoyqW7DFNVqE 2nO5UYAPxdvAPfXx8eO5NfMsnrK6pPm8z73idJZFL5StEKHrUcZdoOVmO 3fqYuHRL56gTNiCXhZgtFP1QFRoS+OO6UZOhMBRr99tsmb99hbP5oUnzj x1i2Opt7Bwy8aXnPDPO7gBgl7N9NtDCIKNgqN/7GP76DY+pK3SF2k/7gr 5zLl8A+6di0DiKm+GKIqQpG2X92P4t5DUoGkxivF42hHZieUAM3Oowtmb T2dKSl6RYqsihfrCgRVpLSIrb0a2zQCMIaqnMIk4TWqjulwxeY2tehQcN Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11023"; a="6431753" X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="6431753" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 16:18:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="15464723" Received: from iweiny-mobl.amr.corp.intel.com (HELO localhost) ([10.213.186.165]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 16:18:21 -0700 From: Ira Weiny Date: Sun, 24 Mar 2024 16:18:22 -0700 Subject: [PATCH 19/26] dax/bus: Factor out dev dax resize logic Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240324-dcd-type2-upstream-v1-19-b7b00d623625@intel.com> References: <20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com> In-Reply-To: <20240324-dcd-type2-upstream-v1-0-b7b00d623625@intel.com> To: Dave Jiang , Fan Ni , Jonathan Cameron , Navneet Singh Cc: Dan Williams , Davidlohr Bueso , Alison Schofield , Vishal Verma , Ira Weiny , linux-btrfs@vger.kernel.org, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org X-Mailer: b4 0.13-dev-2d940 X-Developer-Signature: v=1; a=ed25519-sha256; t=1711322284; l=8758; i=ira.weiny@intel.com; s=20221211; h=from:subject:message-id; bh=ut6MPUSgbN0WUhXp23QFP+26uxY7Nhx7fWMd5btbDxw=; b=NfgJS8i9f/7kiYTas5hrgQ6EXDGgWd7rut5kBmuK/s5UA/sJ/rzt14baQQ/rrk/QppI4rt7ai 8BcSbu6qxB+CDwfWeiyMCUGAD5iOi98+ews/dt2HflYKT80Wc+d6/SO X-Developer-Key: i=ira.weiny@intel.com; a=ed25519; pk=noldbkG+Wp1qXRrrkfY1QJpDf7QsOEthbOT7vm0PqsE= 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 --- Changes for V1 [iweiny: Rebase on new DAX region locking] [iweiny: Reword commit message] [iweiny: Drop reviews] --- drivers/dax/bus.c | 129 +++++++++++++++++++++++++++++++++--------------------- 1 file changed, 79 insertions(+), 50 deletions(-) diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c index 4d5ed7ab6537..bab19fc578d0 100644 --- a/drivers/dax/bus.c +++ b/drivers/dax/bus.c @@ -928,11 +928,9 @@ static int devm_register_dax_mapping(struct dev_dax *dev_dax, int range_id) return 0; } -static int alloc_dev_dax_range(struct dev_dax *dev_dax, u64 start, - resource_size_t size) +static int alloc_dev_dax_range(struct resource *parent, struct dev_dax *dev_dax, + u64 start, resource_size_t size) { - struct dax_region *dax_region = dev_dax->region; - struct resource *res = &dax_region->res; struct device *dev = &dev_dax->dev; struct dev_dax_range *ranges; unsigned long pgoff = 0; @@ -950,14 +948,14 @@ static int alloc_dev_dax_range(struct dev_dax *dev_dax, u64 start, return 0; } - alloc = __request_region(res, start, size, dev_name(dev), 0); + alloc = __request_region(parent, start, size, dev_name(dev), 0); if (!alloc) return -ENOMEM; ranges = krealloc(dev_dax->ranges, sizeof(*ranges) * (dev_dax->nr_range + 1), GFP_KERNEL); if (!ranges) { - __release_region(res, alloc->start, resource_size(alloc)); + __release_region(parent, alloc->start, resource_size(alloc)); return -ENOMEM; } @@ -1110,50 +1108,45 @@ static bool adjust_ok(struct dev_dax *dev_dax, struct resource *res) return true; } -static ssize_t dev_dax_resize(struct dax_region *dax_region, - struct dev_dax *dev_dax, resource_size_t size) +/** + * 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 to be expanded + * @to_alloc: amount of space to alloc; must be <= space available in @parent + * + * Return the amount of space allocated or -ERRNO on failure + */ +static ssize_t dev_dax_resize_static(struct resource *parent, + struct dev_dax *dev_dax, + resource_size_t to_alloc) { - resource_size_t avail = dax_region_avail_size(dax_region), to_alloc; - resource_size_t dev_size = dev_dax_size(dev_dax); - struct resource *region_res = &dax_region->res; - struct device *dev = &dev_dax->dev; struct resource *res, *first; - resource_size_t alloc = 0; int rc; - 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; - - /* - * 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. - */ -retry: - first = region_res->child; - if (!first) - return alloc_dev_dax_range(dev_dax, dax_region->res.start, to_alloc); + first = parent->child; + if (!first) { + rc = alloc_dev_dax_range(parent, dev_dax, + parent->start, to_alloc); + if (rc) + return rc; + return to_alloc; + } - rc = -ENOSPC; for (res = first; res; res = res->sibling) { struct resource *next = res->sibling; + resource_size_t alloc; /* space at the beginning of the region */ - if (res == first && res->start > dax_region->res.start) { - alloc = min(res->start - dax_region->res.start, to_alloc); - rc = alloc_dev_dax_range(dev_dax, dax_region->res.start, alloc); - break; + if (res == first && res->start > parent->start) { + alloc = min(res->start - parent->start, to_alloc); + rc = alloc_dev_dax_range(parent, dev_dax, + parent->start, alloc); + if (rc) + return rc; + return alloc; } alloc = 0; @@ -1162,21 +1155,55 @@ static ssize_t dev_dax_resize(struct dax_region *dax_region, alloc = min(next->start - (res->end + 1), to_alloc); /* space at the end of the region */ - if (!alloc && !next && res->end < region_res->end) - alloc = min(region_res->end - res->end, to_alloc); + if (!alloc && !next && res->end < parent->end) + alloc = min(parent->end - res->end, to_alloc); if (!alloc) continue; if (adjust_ok(dev_dax, res)) { rc = adjust_dev_dax_range(dev_dax, res, resource_size(res) + alloc); - break; + if (rc) + return rc; + return alloc; } - rc = alloc_dev_dax_range(dev_dax, res->end + 1, alloc); - break; + rc = alloc_dev_dax_range(parent, dev_dax, res->end + 1, alloc); + if (rc) + return rc; + return alloc; } - if (rc) - return rc; + + /* available was already calculated and should never be an issue */ + dev_WARN_ONCE(&dev_dax->dev, 1, "space not found?"); + return 0; +} + +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; + + 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; @@ -1283,7 +1310,8 @@ static ssize_t mapping_store(struct device *dev, struct device_attribute *attr, to_alloc = range_len(&r); if (alloc_is_aligned(dev_dax, to_alloc)) - rc = alloc_dev_dax_range(dev_dax, r.start, to_alloc); + rc = alloc_dev_dax_range(&dax_region->res, dev_dax, r.start, + to_alloc); up_write(&dax_dev_rwsem); up_write(&dax_region_rwsem); @@ -1506,7 +1534,8 @@ static struct dev_dax *__devm_create_dev_dax(struct dev_dax_data *data) device_initialize(dev); dev_set_name(dev, "dax%d.%d", dax_region->id, dev_dax->id); - rc = alloc_dev_dax_range(dev_dax, dax_region->res.start, data->size); + rc = alloc_dev_dax_range(&dax_region->res, dev_dax, dax_region->res.start, + data->size); if (rc) goto err_range; -- 2.44.0