Re: [PATCH v7 4/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

[Wei Wang <wei.w.wang@intel.com>]

On 06/08/2018 10:17 AM, Peter Xu wrote:
> On Thu, Jun 07, 2018 at 07:59:22PM +0800, Wei Wang wrote:
> > Not necessarily _need_ to share it, I meant it can be shared using qemu
> > command line.
> > Live migration doesn't happen all the time, and that optimization doesn't
> > run that long, if users want to have other BHs run in this iothread context,
> > they can only create one iothread via the qemu cmd line.
> IMO iothreads and aiocontexts are for event-driven model.

To me it's just a thread which polls for submitted callbacks to run. 
When migration reaches the place that needs to submit the optimization 
function, it calls start() to submit it. I'm not sure why there is a 
worry about what's inside the callback.

> Busy loop
> is not an event-driven model.  Here if we want a busy loop I'll create
> a thread when start page hinting, then join the thread when done.

 The old (v4) implementation worked that way as you mentioned above, 
and Michael suggested to use iothread in the previous discussion. I'm 
fine with both actually. For the virtio part, we've had many 
discussions, I would take the choice I had with Michael before, unless 
there is an obvious advantage (e.g. proved better performance).


> But I'll stop commenting on this.  Please prepare a more clear
> interface for migration in your next post.  I'll read that.

Sure, thanks. The new version is coming soon.




> > > > > I'm a bit curious on how much time will it use to do
> > > > > one round of the free page hints (e.g., an idle guest with 8G mem, or
> > > > > any configuration you tested)?  I suppose during that time the
> > > > > iothread will be held steady with 100% cpu usage, am I right?
> > > > Compared to the time spent by the legacy migration to send free pages, that
> > > > small amount of CPU usage spent on filtering free pages could be neglected.
> > > > Grinding a chopper will not hold up the work of cutting firewood :)
> > > Sorry I didn't express myself clearly.
> > >
> > > My question was that, have you measured how long time it will take
> > > from starting of the free page hints (when balloon state is set to
> > > FREE_PAGE_REPORT_S_REQUESTED), until it completes (when QEMU receives
> > > the VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID, then set the status to
> > > FREE_PAGE_REPORT_S_STOP)?
> > I vaguely remember it's several ms (for around 7.5G free pages) long time
> > ago. What would be the concern behind that number you want to know?
> Because roughly I know the time between two bitmap syncs.  Then I will
> know how possible a free page hinting process won't stop until the
> next bitmap sync happens.

We have a function, stop(), to stop the optimization before the next 
bitmap sync if the optimization is still running. But I never saw that 
case happens (the free page hinting finishes itself before that).

Best,
Wei