linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Cc: sahilmehta17@gmail.com
Subject: Re: [PATCH v6 3/3] powerpc/pseries: Implement indexed-count hotplug memory remove
Date: Mon, 14 Nov 2016 18:58:46 -0600	[thread overview]
Message-ID: <20161115005846.31168.3522@loki> (raw)
In-Reply-To: <20161018172053.37287.78128.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>

Quoting Nathan Fontenot (2016-10-18 12:21:06)
> From: Sahil Mehta <sahilmehta17@gmail.com>
> =

> Indexed-count remove for memory hotplug guarantees that a contiguous block
> of <count> lmbs beginning at a specified <index> will be unassigned (NOT
> that <count> lmbs will be removed). Because of Qemu's per-DIMM memory
> management, the removal of a contiguous block of memory currently
> requires a series of individual calls. Indexed-count remove reduces
> this series into a single call.
> =

> Signed-off-by: Sahil Mehta <sahilmehta17@gmail.com>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> ---
> v2:     -use u32s drc_index and count instead of u32 ic[]
>          in dlpar_memory
> v3:     -add logic to handle invalid drc_index input
> v4:     -none
> v5:     -Update for() loop to start at start_index
> v6:     -none
> =

>  arch/powerpc/platforms/pseries/hotplug-memory.c |   90 +++++++++++++++++=
++++++
>  1 file changed, 90 insertions(+)
> =

> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/power=
pc/platforms/pseries/hotplug-memory.c
> index badc66d..19ad081 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -558,6 +558,92 @@ static int dlpar_memory_remove_by_index(u32 drc_inde=
x, struct property *prop)
>         return rc;
>  }
> =

> +static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index,
> +                                    struct property *prop)
> +{
> +       struct of_drconf_cell *lmbs;
> +       u32 num_lmbs, *p;
> +       int i, rc, start_lmb_found;
> +       int lmbs_available =3D 0, start_index =3D 0, end_index;
> +
> +       pr_info("Attempting to hot-remove %u LMB(s) at %x\n",
> +               lmbs_to_remove, drc_index);
> +
> +       if (lmbs_to_remove =3D=3D 0)
> +               return -EINVAL;
> +
> +       p =3D prop->value;
> +       num_lmbs =3D *p++;
> +       lmbs =3D (struct of_drconf_cell *)p;
> +       start_lmb_found =3D 0;
> +
> +       /* Navigate to drc_index */
> +       while (start_index < num_lmbs) {
> +               if (lmbs[start_index].drc_index =3D=3D drc_index) {
> +                       start_lmb_found =3D 1;
> +                       break;
> +               }
> +
> +               start_index++;
> +       }
> +
> +       if (!start_lmb_found)
> +               return -EINVAL;
> +
> +       end_index =3D start_index + lmbs_to_remove;
> +
> +       /* Validate that there are enough LMBs to satisfy the request */
> +       for (i =3D start_index; i < end_index; i++) {
> +               if (lmbs[i].flags & DRCONF_MEM_RESERVED)
> +                       break;
> +
> +               lmbs_available++;
> +       }
> +
> +       if (lmbs_available < lmbs_to_remove)
> +               return -EINVAL;
> +
> +       for (i =3D start_index; i < end_index; i++) {
> +               if (!(lmbs[i].flags & DRCONF_MEM_ASSIGNED))
> +                       continue;
> +
> +               rc =3D dlpar_remove_lmb(&lmbs[i]);

dlpar_remove_lmb() currently does both offlining of the memory as well
as releasing the LMB back to the platform, but the specification for
hotplug notifications has the following verbage regarding
indexed-count/count identifiers:

'When using =E2=80=9Cdrc count=E2=80=9D or =E2=80=9Cdrc count indexed=E2=80=
=9D as the Hotplug Identifier,
the OS should take steps to verify the entirety of the request can be
satisfied before proceeding with the hotplug / unplug operations. If
only a partial count can be satisfied, the OS should ignore the entirety
of the request. If the OS cannot determine this beforehand, it should
satisfy the hotplug / unplug request for as many of the requested
resources as possible, and attempt to revert to the original OS / DRC
state.'

So doing the dlpar_remove->dlapr_add in case of failure is in line with
the spec, but it should only be done as a last-resort. To me that
suggests that we should be attempting to offline all the LMBs
beforehand, and only after that's successful should we begin attempting
to release LMBs back to the platform. Should we consider introducing
that logic in the patchset? Or maybe as a follow-up?

> +               if (rc)
> +                       break;
> +
> +               lmbs[i].reserved =3D 1;
> +       }
> +
> +       if (rc) {
> +               pr_err("Memory indexed-count-remove failed, adding any re=
moved LMBs\n");
> +
> +               for (i =3D start_index; i < end_index; i++) {
> +                       if (!lmbs[i].reserved)
> +                               continue;
> +
> +                       rc =3D dlpar_add_lmb(&lmbs[i]);
> +                       if (rc)
> +                               pr_err("Failed to add LMB, drc index %x\n=
",
> +                                      be32_to_cpu(lmbs[i].drc_index));
> +
> +                       lmbs[i].reserved =3D 0;
> +               }
> +               rc =3D -EINVAL;
> +       } else {
> +               for (i =3D start_index; i < end_index; i++) {
> +                       if (!lmbs[i].reserved)
> +                               continue;
> +
> +                       pr_info("Memory at %llx (drc index %x) was hot-re=
moved\n",
> +                               lmbs[i].base_addr, lmbs[i].drc_index);
> +
> +                       lmbs[i].reserved =3D 0;
> +               }
> +       }
> +
> +       return rc;
> +}
> +
>  #else
>  static inline int pseries_remove_memblock(unsigned long base,
>                                           unsigned int memblock_size)
> @@ -853,6 +939,10 @@ int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
>                 } else if (hp_elog->id_type =3D=3D PSERIES_HP_ELOG_ID_DRC=
_INDEX) {
>                         drc_index =3D hp_elog->_drc_u.drc_index;
>                         rc =3D dlpar_memory_remove_by_index(drc_index, pr=
op);
> +               } else if (hp_elog->id_type =3D=3D PSERIES_HP_ELOG_ID_DRC=
_IC) {
> +                       count =3D hp_elog->_drc_u.indexed_count[0];
> +                       drc_index =3D hp_elog->_drc_u.indexed_count[1];
> +                       rc =3D dlpar_memory_remove_by_ic(count, drc_index=
, prop);
>                 } else {
>                         rc =3D -EINVAL;
>                 }
>=20

  parent reply	other threads:[~2016-11-15  0:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-18 17:20 [PATCH v6 0/3] powerpc/pseries: Implement indexed-count memory hotplug Nathan Fontenot
2016-10-18 17:20 ` [PATCH v6 1/3] powerpc/pseries: Correct possible read beyond dlpar sysfs buffer Nathan Fontenot
2016-10-27 14:20   ` John Allen
2016-10-18 17:20 ` [PATCH v6 2/3] powerpc/pseries: Implement indexed-count hotplug memory add Nathan Fontenot
2016-10-27 14:21   ` John Allen
2016-10-18 17:21 ` [PATCH v6 3/3] powerpc/pseries: Implement indexed-count hotplug memory remove Nathan Fontenot
2016-10-27 14:22   ` John Allen
2016-11-15  0:58   ` Michael Roth [this message]
2016-11-15 20:09     ` Nathan Fontenot

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=20161115005846.31168.3522@loki \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=sahilmehta17@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).