On 27/09/16 10:14, Reza Arbab wrote:
> On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote:
>> In any case, if the memory hasn't been hotplug, this shouldn't be necessary as we shouldn't be considering it for allocation.
>
> Right. To be clear, the background info I put in the commit log refers to x86, where the SRAT can describe movable nodes which exist at boot. They're trying to avoid allocations from those nodes before they've been identified.
>
> On power, movable nodes can only exist via hotplug, so that scenario can't happen. We can immediately go back to top-down allocation. That is the missing call being added in the patch.
>
Can we fix cmdline_parse_movable_node() to do the right thing? I suspect that
code is heavily x86 only in the sense that no other arch needs it.
Balbir Singh.
On Tue, Oct 04, 2016 at 11:48:30AM +1100, Balbir Singh wrote:
>On 27/09/16 10:14, Reza Arbab wrote:
>> Right. To be clear, the background info I put in the commit log
>> refers to x86, where the SRAT can describe movable nodes which exist
>> at boot. They're trying to avoid allocations from those nodes before
>> they've been identified.
>>
>> On power, movable nodes can only exist via hotplug, so that scenario
>> can't happen. We can immediately go back to top-down allocation. That
>> is the missing call being added in the patch.
>
>Can we fix cmdline_parse_movable_node() to do the right thing? I
>suspect that code is heavily x86 only in the sense that no other arch
>needs it.
Good idea. We could change it so things only go bottom-up on x86 in the
first place.
A nice consequence is that CONFIG_MOVABLE_NODE would then basically be
usable on any platform with memory hotplug, not just PPC64 and X86_64.
I'll see if I can move the relevant code into an arch_*() call or
otherwise factor it out.
--
Reza Arbab