Re: [Xen-devel] [PATCH] Fix performance problems with mprotect()

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 7/1/08 17:05, "Bruce Rogers" <BROGERS@xxxxxxxxxx> wrote:

>> An additional piece of concern regarding the bit assignments of
>> MMU_FLAG_RANGE_UPDATE's val parameter (Keir, maybe you need to
>> comment on this one): The whole mmu_update interface, being
>> defined in public/xen.h, is supposed to be sufficiently architecture
>> neutral, which it won't be anymore in the way it currently is being
>> modified. But maybe I'm mistaken and the interface's declaration is
>> just badly placed (would apply to the mmuext interface then, too)?
> I should point out that the MMU_FLAG_RANGE_UPDATE hypercall didn't end up
> being needed for improving the SAP test, but does get invoked by other uses of
> mprotect() and feel that it is useful.  As it stands I've only implemented x86
> version of this, other architecture owners would need to do the same.
> Perhaps as far as what is presented in public/xen.h, we should just have a
> more generic description (not pointing out the format) and leave it up to each
> architecture as to what specific format for the val member makes sense.

No other architecture uses do_mmu_update(). The public definitions are
simply in the wrong header file.

Is MMU_FLAG_RANGE_UPDATE really useful if you have MMU_ATOMIC_PT_UPDATE? If
it is it's presumably a performance issue, and the question should be: why
is a sequence MMU_ATOMIC_PT_UPDATE slower than MMU_FLAG_RANGE_UPDATE, and
can we make it fast enough that MMU_FLAG_RANGE_UPDATE is redundant?

Also, the documentation for MMU_ATOMIC_PT_UDATE in xen.h is possibly
incorrect. It doesn't make sense to me -- are your meanings for ptr[2:] and
val actually correct?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel