Re: [PATCH RFC] drivers/base/memory.c: indicate all memory blocks as removable

[David Hildenbrand]

On 27.01.20 10:23, Michal Hocko wrote:
> On Fri 24-01-20 13:10:22, Fontenot, Nathan wrote:
>> It's been awhile since I've looked at the powerpc-utils drmgr command and
>> pseries DLPAR code but a quick scan makes and it appears that it hasn't changed
>> too much. Given that, some thoughts.
>>
>> The sysfs 'removable' file was a great help when memory DLPAR was driven
>> from userspace in the powerpc-utils drmgr command. Having this check did improve
>> performance though I can't point to any numbers.
> 
> Do you still have an access to the HW to give it a try?
> 
>> Currently, memory DLPAR is done completely in the kernel. The request is
>> initiated from drmgr writing to /sys/kernel/dlpar (for pHyp partitions)
>> or from a hotplug interrupt (for guests). I don't believe the 'removable'
>> sysfs file is used in either of these paths by drmgr. The only time it is
>> used is on older kernels that do not support in-kernel memory DLPAR.
>>
>> Given this, I don't think removing the 'removable' sysfs file would cause any
>> issues for the drmgr command. The only scenario I can think of is using an old
>> version of drmgr that does not support in-kernel memory DLPAR on a new kernel
>> where the 'removable' sysfs file has been removed. This doesn't seem likely
>> though and drmgr could be updated to detect this.
> 
> Thanks for the information!
> 

(weird, I never received the mail from Nathan - mail deliver issues
brighten my Mondays :) )

Thanks for the information! Looks like powerpc indeed can live without
the interface (old userspace on shiny new kernel would in the worst case
simply be slower).

Of course, the alternative to returning always "removable" would be to
drop the attribute completely. So, if the "removable" attribute is not
present

- powerpc-utils will fallback to "removable"
- lsmem will fallback to "not removable". Could be because it assumes
  "old kernel with lacking offlining capability".

I don't know how likely it is that this could break custom scripts that
used the returned value for any purpose (e.g., use it as an indicator if
memory offlining is supported at all etc.).

-- 
Thanks,

David / dhildenb