[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 30/51] ram: Move src_page_req* to RAMState
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH 30/51] ram: Move src_page_req* to RAMState |
Date: |
Sat, 1 Apr 2017 15:15:01 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Fri, Mar 31, 2017 at 04:25:56PM +0100, Dr. David Alan Gilbert wrote:
> * Peter Xu (address@hidden) wrote:
> > On Thu, Mar 23, 2017 at 09:45:23PM +0100, Juan Quintela wrote:
> > > This are the last postcopy fields still at MigrationState. Once there
> >
> > s/This/These/
> >
> > > Move MigrationSrcPageRequest to ram.c and remove MigrationState
> > > parameters where appropiate.
> > >
> > > Signed-off-by: Juan Quintela <address@hidden>
> >
> > Reviewed-by: Peter Xu <address@hidden>
> >
> > One question below though...
> >
> > [...]
> >
> > > @@ -1191,19 +1204,18 @@ static bool get_queued_page(RAMState *rs,
> > > MigrationState *ms,
> > > *
> > > * It should be empty at the end anyway, but in error cases there may
> > > * xbe some left.
> > > - *
> > > - * @ms: current migration state
> > > */
> > > -void flush_page_queue(MigrationState *ms)
> > > +void flush_page_queue(void)
> > > {
> > > - struct MigrationSrcPageRequest *mspr, *next_mspr;
> > > + struct RAMSrcPageRequest *mspr, *next_mspr;
> > > + RAMState *rs = &ram_state;
> > > /* This queue generally should be empty - but in the case of a failed
> > > * migration might have some droppings in.
> > > */
> > > rcu_read_lock();
> >
> > Could I ask why we are taking the RCU read lock rather than the mutex
> > here?
>
> It's a good question whether we need anything at all.
> flush_page_queue is called only from migrate_fd_cleanup.
> migrate_fd_cleanup is called either from a backhalf, which I think has the
> bql,
> or from a failure path in migrate_fd_connect.
> migrate_fd_connect is called from migration_channel_connect and
> rdma_start_outgoing_migration
> which I think both end up at monitor commands so also in the bql.
>
> So I think we can probably just lose the rcu_read_lock/unlock.
Thanks for the confirmation.
(ps: even if we are not with bql, we should not need this
rcu_read_lock, right? My understanding is: if we want to protect
src_page_requests, we should need the mutex, not rcu lock; while for
the memory_region_unref() since we have had the reference, looks like
we don't need any kind of locking either)
>
> Dave
>
> >
> > > - QSIMPLEQ_FOREACH_SAFE(mspr, &ms->src_page_requests, next_req,
> > > next_mspr) {
> > > + QSIMPLEQ_FOREACH_SAFE(mspr, &rs->src_page_requests, next_req,
> > > next_mspr) {
> > > memory_region_unref(mspr->rb->mr);
> > > - QSIMPLEQ_REMOVE_HEAD(&ms->src_page_requests, next_req);
> > > + QSIMPLEQ_REMOVE_HEAD(&rs->src_page_requests, next_req);
> > > g_free(mspr);
> > > }
> > > rcu_read_unlock();
> >
> > Thanks,
> >
> > -- peterx
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK
-- peterx
- Re: [Qemu-devel] [PATCH 30/51] ram: Move src_page_req* to RAMState,
Peter Xu <=