| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home