Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Nathan Lynch <nathanl@linux.ibm.com>
To:     Scott Cheloha <cheloha@linux.ibm.com>
Cc:     Nathan Fontenont <ndfont@gmail.com>,
        Rick Lindsley <ricklind@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH] pseries/hotplug-memory: remove dlpar_memory_{add,remove}_by_index() functions
In-Reply-To: <20200127200839.12441-1-cheloha@linux.ibm.com>
References: <20200127200839.12441-1-cheloha@linux.ibm.com>
Date:   Mon, 10 Feb 2020 14:28:49 -0600
Message-ID: <87ftfimbjy.fsf@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Scott Cheloha <cheloha@linux.ibm.com> writes:
> The dlpar_memory_{add,remove}_by_index() functions are just special
> cases of their dlpar_memory_{add,remove}_by_ic() counterparts where
> the LMB count is 1.

I wish that were the case, but there are (gratuitous?) differences:

- dlpar_memory_remove_by_ic() checks DRCONF_MEM_RESERVED and
  DRCONF_MEM_ASSIGNED flags; dlpar_memory_remove_by_index() does not.
- dlpar_memory_remove_by_ic() attempts to roll back failed removal;
  dlpar_memory_remove_by_index() does not.

I'm not sure how much either of these gets used in practice. AFAIK the
usual HMC/drmgr-driven workflow tends to exercise
dlpar_memory_remove_by_count().

I agree this code needs consolidation, but we should proceed a little
carefully because it's likely going to entail changing some user-visible
behaviors.