This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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