On Thu, 2019-07-25 at 14:25 -0400, Nitesh Narayan Lal wrote: > On 7/25/19 12:16 PM, Alexander Duyck wrote: > > On Thu, 2019-07-25 at 11:16 -0400, Michael S. Tsirkin wrote: > > > On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote: > > > > On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote: > > > > > On 7/24/19 6:03 PM, Alexander Duyck wrote: > > > > > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote: > > > > > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote: > > > > > > > > From: Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx> > > > > > > > > > > > > > > > <snip> > > Ideally we should be able > > to provide the hints and have them feed whatever is supposed to be using > > them. So for example I could probably look at also clearing the bitmaps > > when migration is in process. > > > > Also, I am wonder if the free page hints would be redundant with the form > > of page hinting/reporting that I have since we should be migrating a much > > smaller footprint anyway if the pages have been madvised away before we > > even start the migration. > > > > > FWIW Nitesh's RFC does not have this limitation. > > Yes, but there are also limitations to his approach. For example the fact > > that the bitmap it maintains is back to being a hint rather then being > > very exact. > > True. > > > > As a result you could end up walking the bitmap for a while > > clearing bits without ever finding a free page. > > Are referring to the overhead which will be introduced due to bitmap scanning on > very large guests? Yes. One concern I have had is that for large memory footprints the RFC would end up having a large number of false positives on an highly active system. I am worried it will result in a feedback loop where having more false hits slows down your processing speed, and the slower your processing speed the more likely you are to encounter more false hits.
