>>>>> I can see why, but I really can't see what else to do without breaking >>>>> existing, supported, working (albeit by accident) setups. >>>> >>>> Is there any reason to use this more complicated "allow random freeing" >>>> approach over a simplistic sequential freeing I propose? Then we can >>>> simply migrate the last freed page and should be fine. >>> >>> Well.. your approach is probably simpler in terms of the calculations >>> that need to be done, though only very slightly. I think my approach >>> is conceptually clearer though, since we're explicitly checking for >>> exactly the condition we need, rather than something we thing should >>> match up with that condition. >> >> I prefer to keep it simple where possible. We expect sequential freeing, >> so it's easy to implement with only one additional uint64_t that can be >> easily migrated. Having to use bitmaps + alloc/free is not really needed. >> >> If you insist, at least try to get rid of the malloc to e.g. simplify >> migration. > > I don't think there's really anything to do for migration; we already > effectively lose the state of the balloon across migration. I think > it's fine to lose a little extra transitional state.
Yeah, I guess it would only make sense when trying to avoid misleading warnings (depending on which approach you'll use for when to report warnings). -- Thanks, David / dhildenb
