| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] turn off writable page tables
On 31 Jul 2006, at 20:56, Zachary Amsden wrote:
If the run-time check cost really isn't an issue (I'd like to see
numbers), we'd likely use this new interface in preference to
implicitly batched writable pagetables and would support its
inclusion in the kernel.
Sorry about not having numbers. My biggest question is - do you need
any other information than simply a single state variable to use
explicit batching? I thought, and Jeremy and Chris both pointed out
as well, that Xen could potentially use the information about which PT
to unhook to take advantage of writable pagetables. But, if that is
not the direction you are going, then it seems this information is not
so relevant for the explicit batching.
If the guest gives explicit hints, and the extra branch on set_pte does
not hurt, then I think it makes sense to do straightforward explicit
batching. Providing a PT page hint sounds like it could be ambiguous in
some contexts too (e.g., the fork loop modifies two PT pages at a
time).
The explicit batching does have one disadvantage without writable
page tables, which is a potential long term maintenance / correctness
issue - you must remove read hazards from these encapsulated paths.
That is not so hard to do, and not a large general problem, because
the batching is explicit rather than implicit, so you can pick paths
to batch that are small, compact, and easy to reason about. But
nevertheless, a point I would like to make sure you are comfortable
with before we all decide these hooks will work for everyone.
Yes, that's why we moved away from this approach before. But previously
we did it for *all* pagetable updates, which was a pain. Doing it just
for a few important cases, and having the hooks maintained in upstream
Linux, makes this rather less of a headache.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home