Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH RESEND] cpu/hotplug: Wait for cpu_hotplug to be enabled in cpu_up/down | Date | Mon, 03 Feb 2020 19:08:03 +0100 |
| |
Matija,
Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> writes:
> Heavier user of cpu_hotplug_enable/disable is pci_device_probe yielding > errors on bringing cpu cores up/down if pci devices are getting probed. > Situation in which pci devices are getting probed and having cpus going > down/up is valid situation.
So what?. User space has to handle -EBUSY properly and it was possible even before that PCI commit that the online/offline operation request returned -EBUSY.
> Problem was observed on x86 board by having partitioning of the system > to RT/NRT cpu sets failing (of which part is to bring cpus down/up via > sysfs) if pci devices would be getting probed at the same time. This is
I have no idea why you need to offline/online CPUs to partition a system. There are surely more sensible ways to do that, but that's not part of this discussion.
> confusing for userspace as dependency to pci devices is not clear.
What's confusing about a EBUSY return code? It's pretty universaly used in situations where a facility is temporarily busy. If it's not sufficiently documented, why EBUSY can be returned and what that means, then this needs to be improved.
> Fix this behavior by waiting for cpu hotplug to be ready. Return -EBUSY > only after hotplugging was not enabled for about 10 seconds.
There is nothing to fix here, really. Fix the user space handling which fails to handle EBUSY. Just because this commit made it more likely that EBUSY is returned does not justify this horrid hack.
Thanks,
tglx
| |