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
