On Wed, Jan 22, 2020 at 11:09 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Wed 22-01-20 19:46:15, David Hildenbrand wrote: > > On 22.01.20 19:38, Michal Hocko wrote: > [...] > > > How exactly is check + offline more optimal then offline which makes > > > check as its first step? I will get to your later points after this is > > > clarified. > > > > Scanning (almost) lockless is more efficient than bouncing back and > > forth with the device_hotplug_lock, mem_hotplug_lock, cpu_hotplug_lock > > and zone locks - as far as I understand. > > All but the zone lock shouldn't be really contended and as such > shouldn't cause any troubles. zone->lock really depends on the page > allocator usage of course. But as soon as we have a contention then it > is just more likely that the result is less reliable. > > I would be also really curious about how much actual time could be saved > by this - some real numbers - because hotplug operations shouldn't > happen so often that this would stand out. At least that is my > understanding. > > > And as far as I understood, that was the whole reason of the original > > commit. > > Well, I have my doubts but it might be just me and I might be wrong. My > experience from a large part of the memory hotplug functionality is that > it was driven by a good intention but without a due diligence to think > behind the most obvious usecase. Having a removable flag on the memblock > sounds like a neat idea of course. But an inherently racy flag is just > borderline useful. > > Anyway, I will stop at this moment and wait for real usecases. ...that and practical numbers showing that optimizing an interface that can at best give rough estimate answers is worth the code change.
