[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] pagetable pinning question

> I think it would.  In NetBSD PDs are managed in a cached pool, i.e. the pool
> items are initialized by the pool system and must be returned to the pool in
> an initialized/clean state.  I have the pool item constructor pin the pages
> and the destructor unpin the pages.  I would expect a problem when the PD's
> page is released from the pool (the page is unpinned) while it's still
> mapped in another PD?  It won't fail but leave the page mapped as an L1 page
> while it's untyped?

That is correct (except it will remain pinned as an L2 table -- many
people have told me that I have L1 and L2 the wrong way round!). 
> The alternate PD mapping are left lingering in case the same mapping is
> requested again.  It would be possibly to always kill the alternate mapping
> (which we do on MP) but it requires a tlbflush (I had inadvertedly commented
> out the tlbflush and the results were quite mysterious ;-))
> The destructor would then have to check all PDs to see if the to be
> destroyed PD is mapped in any and clear the mapping.  That would be
> reasonable since destruction happens only when the kernel's VA usage
> requires additional PTs which causes the pool cache to be flushed or when
> unused items from the pool are drained because of resource shortage.
> So, for case 1, would you then just increment the page's type count in
> get_twisted_l2_table an decrement it in mod_l2_entry when put_l1_table
> fails?

Actually, it now occurs to me that this strategy has a nasty flaw (at
least it does in the v1.3 page-management code). We can end up with
circular references: e.g. PD A maps PD B, and vice versa. Unless code
is added to detect such loops this will mess up page-frame
reclamation since they hold each other as type 'L2'. :-(

Hmmmm... I think a simple hack that allows these circular references
is sufficient in 1.2 --- we don't properly do reference-count-based
reclamation in Xen 1.2. Xen 1.3 is going to need some more thought --
wet towel time :-)

> > > I guess a work around would be to switch to the inactive pagetable and
> > > switch back when the mapping is no longer needed...
> >
> > I guess it depends how often a process accesses another's PTEs. Maybe
> > fork times and CoW-fault latencies might be slowed down if you took
> > this approach?
> yes, it's preferable to use the alternate mapping if possible...
> > I can remove the check in Xen and requrie the guest to be involved in
> > cleaning up when a page directory is released, if this is a suitable
> > approach for NetBSD.
> yes please, I think it is.  I have removed the check in my Xen but without
> the added ref counting and without the extra cleaning up in the destructor.

I expect your current hack can lead to reference-count inconsistencies
within Xen. We need to sort this out as a priority. I'll fix for 1.2
tomorrow and then think harder about the correct solution for 1.3.

 -- Keir

The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.