On Mon 27-01-20 10:33:55, 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? > > > >> 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.). Our long term tradition with user visible knobs is to keep them in place and simply fake the answer. This seems to be a safer option and less likely to lead to failures. -- Michal Hocko SUSE Labs
