On Thu, Nov 28, 2019 at 1:22 AM Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Nov 27, 2019 at 01:55:02PM -0800, Alexander Duyck wrote: < snip > > > > > > > Which in itself could be an optimisation patch. Maybe it'll be enough that > > > keeping track of the count is not worthwhile. Either way, the separate > > > patch could have supporting data on how much it improves the speed of > > > reporting pages so it can be compared to any other optimisation that > > > may be proposed. Supporting data would also help make the case that any > > > complexity introduced by the optimisation is worthwhile. > > > > I'll see what I can do to break this apart. I'm just not a fan of redoing > > the work multiple times so that I can have a non-optimized version versus > > an optimized one. > > > > While I understand that, right now the optimisations are blocking the > feature itself which is also not a situation you want to be in. I'll see what I can do. I can probably replace the reference count and zone flags with an atomic state in the prdev that cycles between inactive, requested, and active. With that I can at least guarantee that we shouldn't have any races that result in us missing freed pages. The only downside is that I have to keep a boolean in the __free_one_page call so that when we free back the reported pages we don't retrigger the reporting and cause an infinite loop.
