>Your understanding and observation is correct. The trade-off of
>that option is that we have to trash the whole cache for
>a vcode page if we find the dirty bit set.
Okay, I still don't think I understood correctly. Is Jens correct, that we
map the scanned page in the I-cache while we map the original page in the
D-cache ? I didn't realise that, I thought we used split-I/D in order to
*trap* writes to the code page. If we do this, then there is no problem.
However, if we can't do this, then we do have a problem -- after all, then
*writes* to the page would go to the scanned page and NOT to the original ---
and AFAIK, there is no way we could then separate out these writes back into
the original page, so we wouldn't be able to rescan either.
>As to when to dump the cache, we check before transferring
>control to each vcode page. If clean, we can use the vcode
>cache, if dirty we have to rescan.
I'm starting to doubt in the practicability of this method. Trapping on
page boundaries is slow... and even if we use a "mixed" case, there is no
way we can separate out page-boundary transfers to pages in the two modes (or
is there ?) So we'd get an overall performance degrade. Does this really weigh
up to the performance gain we get, if there is a lot of data writing to the
code page ? Hopefully, this will be a rarity anyway.
-- Ramon
