David S. Ahern wrote:
[dsa] No. I saw the same problem with the flood count at 5. The
attachment in the last email shows kvm_stat data during a kscand event.
The data was collected with the patch you posted. With the flood count
at 3 the mmu cache/flood counters are in the 18,000/sec and pte updates
at ~50,000/sec and writes at 70,000/sec. With the flood count at 5
mmu_cache/flood drops to 0 and pte updates and writes both hit
180,000+/second. In both cases these last for 30 seconds or more. I only
included data for the onset as it's pretty flat during the kscand activity.
It makes sense. We removed a flooding false positive, and introduced a
false negative.
The guest access sequence is:
- point kmap pte at page table
- use the new pte to access the page table
Prior to the patch, the mmu didn't see the 'use' part, so it concluded
the kmap pte would be better off unshadowed. This shows up as a high
flood count.
After the patch, this no longer happens, so the sequence can repreat for
long periods. However the pte that is the result of the 'use' part is
never accessed, so it should be detected as flooded! But our flood
detection mechanism looks at one page at a time (per vcpu), while there
are two pages involved here.
There are (at least) three options available:
- detect and special-case this scenario
- change the flood detector to be per page table instead of per vcpu
- change the flood detector to look at a list of recently used page
tables instead of the last page table
I'm having a hard time trying to pick between the second and third options.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
