All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: stable <stable@vger.kernel.org>,
	linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCHv2 1/2] libnvdimm: Use max contiguous area for namespace size
Date: Thu, 12 Jul 2018 09:31:12 -0600	[thread overview]
Message-ID: <20180712153111.GA16325@localhost.localdomain> (raw)
In-Reply-To: <CAPcyv4jQNRTt=81bUzs1amoWytQdQx3TjG=FAQzT=6HhEk0NBA@mail.gmail.com>

On Mon, Jul 09, 2018 at 02:49:54PM -0700, Dan Williams wrote:
> On Mon, Jul 9, 2018 at 8:44 AM, Keith Busch <keith.busch@intel.com> wrote:
> > On Fri, Jul 06, 2018 at 03:25:15PM -0700, Dan Williams wrote:
> >> This is going in the right direction... but still needs to account for
> >> the blk_overlap.
> >>
> >> So, on a given DIMM BLK capacity is allocated from the top of DPA
> >> space going down and PMEM capacity is allocated from the bottom of the
> >> DPA space going up.
> >>
> >> Since BLK capacity is single DIMM, and PMEM capacity is striped you
> >> could get into the situation where one DIMM is fully allocated for BLK
> >> usage and that would shade / remove the possibility to use the PMEM
> >> capacity on the other DIMMs in the PMEM set. PMEM needs all the same
> >> DPAs in all the DIMMs to be free.
> >>
> >> >
> >> > ---
> >> > diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
> >> > index 8d348b22ba45..f30e0c3b0282 100644
> >> > --- a/drivers/nvdimm/dimm_devs.c
> >> > +++ b/drivers/nvdimm/dimm_devs.c
> >> > @@ -536,6 +536,31 @@ resource_size_t nd_blk_available_dpa(struct nd_region *nd_region)
> >> >         return info.available;
> >> >  }
> >> >
> >> > +/**
> >> > + * nd_pmem_max_contiguous_dpa - For the given dimm+region, return the max
> >> > + *                             contiguous unallocated dpa range.
> >> > + * @nd_region: constrain available space check to this reference region
> >> > + * @nd_mapping: container of dpa-resource-root + labels
> >> > + */
> >> > +resource_size_t nd_pmem_max_contiguous_dpa(struct nd_region *nd_region,
> >> > +                                          struct nd_mapping *nd_mapping)
> >> > +{
> >> > +       struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
> >> > +       resource_size_t max = 0;
> >> > +       struct resource *res;
> >> > +
> >> > +       if (!ndd)
> >> > +               return 0;
> >> > +
> >> > +       for_each_dpa_resource(ndd, res) {
> >> > +               if (strcmp(res->name, "pmem-reserve") != 0)
> >> > +                       continue;
> >> > +               if (resource_size(res) > max)
> >>
> >> ...so instead straight resource_size() here you need trim the end of
> >> this "pmem-reserve" resource to the start of the first BLK allocation
> >> in any of the DIMMs in the set.
> >>
> >> See blk_start calculation in nd_pmem_available_dpa().

Okay, I think I've got it this time. __reserve_free_pmem won't reserve a
resource above the first blk resource, so we can't get some fragmented
alternating mix of blk and pmem within a dimm. With that in mind, if
we reserve pmem across all dimms in a region, take the largest reserved
pmem within each dimm, then take the smallest of those across all dimms,
that should be the largest allocatable pmem extent.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>,
	Dave Jiang <dave.jiang@intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	stable <stable@vger.kernel.org>
Subject: Re: [PATCHv2 1/2] libnvdimm: Use max contiguous area for namespace size
Date: Thu, 12 Jul 2018 09:31:12 -0600	[thread overview]
Message-ID: <20180712153111.GA16325@localhost.localdomain> (raw)
In-Reply-To: <CAPcyv4jQNRTt=81bUzs1amoWytQdQx3TjG=FAQzT=6HhEk0NBA@mail.gmail.com>

On Mon, Jul 09, 2018 at 02:49:54PM -0700, Dan Williams wrote:
> On Mon, Jul 9, 2018 at 8:44 AM, Keith Busch <keith.busch@intel.com> wrote:
> > On Fri, Jul 06, 2018 at 03:25:15PM -0700, Dan Williams wrote:
> >> This is going in the right direction... but still needs to account for
> >> the blk_overlap.
> >>
> >> So, on a given DIMM BLK capacity is allocated from the top of DPA
> >> space going down and PMEM capacity is allocated from the bottom of the
> >> DPA space going up.
> >>
> >> Since BLK capacity is single DIMM, and PMEM capacity is striped you
> >> could get into the situation where one DIMM is fully allocated for BLK
> >> usage and that would shade / remove the possibility to use the PMEM
> >> capacity on the other DIMMs in the PMEM set. PMEM needs all the same
> >> DPAs in all the DIMMs to be free.
> >>
> >> >
> >> > ---
> >> > diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
> >> > index 8d348b22ba45..f30e0c3b0282 100644
> >> > --- a/drivers/nvdimm/dimm_devs.c
> >> > +++ b/drivers/nvdimm/dimm_devs.c
> >> > @@ -536,6 +536,31 @@ resource_size_t nd_blk_available_dpa(struct nd_region *nd_region)
> >> >         return info.available;
> >> >  }
> >> >
> >> > +/**
> >> > + * nd_pmem_max_contiguous_dpa - For the given dimm+region, return the max
> >> > + *                             contiguous unallocated dpa range.
> >> > + * @nd_region: constrain available space check to this reference region
> >> > + * @nd_mapping: container of dpa-resource-root + labels
> >> > + */
> >> > +resource_size_t nd_pmem_max_contiguous_dpa(struct nd_region *nd_region,
> >> > +                                          struct nd_mapping *nd_mapping)
> >> > +{
> >> > +       struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
> >> > +       resource_size_t max = 0;
> >> > +       struct resource *res;
> >> > +
> >> > +       if (!ndd)
> >> > +               return 0;
> >> > +
> >> > +       for_each_dpa_resource(ndd, res) {
> >> > +               if (strcmp(res->name, "pmem-reserve") != 0)
> >> > +                       continue;
> >> > +               if (resource_size(res) > max)
> >>
> >> ...so instead straight resource_size() here you need trim the end of
> >> this "pmem-reserve" resource to the start of the first BLK allocation
> >> in any of the DIMMs in the set.
> >>
> >> See blk_start calculation in nd_pmem_available_dpa().

Okay, I think I've got it this time. __reserve_free_pmem won't reserve a
resource above the first blk resource, so we can't get some fragmented
alternating mix of blk and pmem within a dimm. With that in mind, if
we reserve pmem across all dimms in a region, take the largest reserved
pmem within each dimm, then take the smallest of those across all dimms,
that should be the largest allocatable pmem extent.

  reply	other threads:[~2018-07-12 15:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 20:17 [PATCHv2 1/2] libnvdimm: Use max contiguous area for namespace size Keith Busch
2018-07-05 20:17 ` Keith Busch
2018-07-05 20:17 ` [PATCHv2 2/2] libnvdimm: Export max available extent Keith Busch
2018-07-05 21:13   ` Dan Williams
2018-07-05 21:13 ` [PATCHv2 1/2] libnvdimm: Use max contiguous area for namespace size Dan Williams
2018-07-05 21:13   ` Dan Williams
2018-07-06  0:12   ` Dan Williams
2018-07-06  0:12     ` Dan Williams
2018-07-06  1:25 ` Dan Williams
2018-07-06  1:25   ` Dan Williams
2018-07-06  1:48   ` Dan Williams
2018-07-06  1:48     ` Dan Williams
2018-07-06 22:06     ` Keith Busch
2018-07-06 22:06       ` Keith Busch
2018-07-06 22:25       ` Dan Williams
2018-07-06 22:25         ` Dan Williams
2018-07-09 15:44         ` Keith Busch
2018-07-09 15:44           ` Keith Busch
2018-07-09 21:49           ` Dan Williams
2018-07-09 21:49             ` Dan Williams
2018-07-12 15:31             ` Keith Busch [this message]
2018-07-12 15:31               ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180712153111.GA16325@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.