On 1/27/2020 3:33 AM, David Hildenbrand wrote: > 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? No, I no longer have access to Power hardware. -Nathan >> >>> 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.). >
