Re: [Xen-devel] [PATCH 5 of 6] [RFC] x86/mm: use wait queues for mem_paging

[Olaf Hering <olaf@xxxxxxxxx>]

On Mon, Feb 27, Tim Deegan wrote:

> At 14:45 +0100 on 24 Feb (1330094744), Olaf Hering wrote:
> > >  #ifdef __x86_64__
> > > +    if ( p2m_is_paging(*t) && (q & P2M_ALLOC)
> > > +         && p2m->domain == current->domain ) 
> > > +    {
> > > +        if ( locked )
> > > +            gfn_unlock(p2m, gfn, 0);
> > > +
> > > +        /* Ping the pager */
> > > +        if ( *t == p2m_ram_paging_out || *t == p2m_ram_paged )
> > > +            p2m_mem_paging_populate(p2m->domain, gfn);
> > > +
> > > +        /* Wait until the pager finishes paging it in */
> > > +        current->arch.mem_paging_gfn = gfn;
> > > +        wait_event(current->arch.mem_paging_wq, ({
> > > +                    int done;
> > > +                    mfn = p2m->get_entry(p2m, gfn, t, a, 0, page_order);
> > > +                    done = (*t != p2m_ram_paging_in);
> > 
> > I assume p2m_mem_paging_populate() will not return until the state is
> > forwarded to p2m_ram_paging_in.  Maybe p2m_is_paging(*t) would make it
> > more obvious what this check is supposed to do.
> 
> But it would be wrong.  If the type anything other than
> p2m_ram_paging_in, then we can't be sure that the pager is working on
> unblocking us.

Not really wrong. I think it depends what will happen to the p2mt once
it leaves the paging state and once the condition in wait_event() is
executed again. Now I see what its supposed to mean, it enters
wait_event() with p2m_ram_paging_in and it is supposed to leave once the
type changed to something else. It works because the page-in path has
now only one p2mt, not two like a few weeks ago.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel