Kevin P. Lawton wrote:
> Option (2) has the benefit of allowing both reads and writes to
> occur to vcode pages without generating an exception. The tradeoff
> is that we only have the option to dump an entire vcode page
> if the page is dirty.
>
> Option (1) incurrs a write exception, but we have the option of
> emulating the instruction (and write) so we can possible keep
> some or all of the vcode cache for that page intact.
Sounds like a difficult choice -- I'm not so much worried about
self-modifying code (it's BOUND to be slow, even on a REAL x86)
but about shared code/data pages (most compilers don't do this,
but you see this a lot with hand-written assembly, and that just
may be the way the tightest loops in the kernel are coded.)
I guess the best choice typically depends on the code you run in
the VM. As we do not know this in advance, I guess it would be
possible to change policy dynamically, using considerations such
as
- What is the relative frequency of data access vs. execute access
- What part of the page is used for data/code
- How much longer would it take to re-scan all the code, compared
to the time a write fault takes?
OTOH, implementing this sounds rather complicated for a first
attempt. If we assume that a code page is used primarily for
code I'd go with (1), for now.
If we want to implement dynamics policies, I'd suggest a method
like this: start off with (1), and increase a counter every time
the page is written to. When the counter exceeds a certain value
(which should somehow depend on the percentage of the page
that has been scanned), switch to (2).
What do you think ?
-- Ramon
