On Mon, May 18, 2026, Wu Fei wrote: > On 5/15/26 21:51, Sean Christopherson wrote: > > On Wed, May 13, 2026, Wu Fei wrote: > > > On 5/13/26 08:03, Sean Christopherson wrote: > > > > On Mon, May 11, 2026, [email protected] wrote: > > > > > > > > > > Unit is introduced to replace the default 1ms if specified in command > > > > > line. The following test can't trigger failure on my riscv vm: > > > > > > > > Failure of what? And does the failure really not reproduce with a > > > > higher interval? > > > > > > On riscv, it fails to write protect some pages with valid page table entry > > > then loses track of dirty pages. Higher interval doesn't help because only > > > the first usleep matters, after the first collect_dirty_pages, all dirty > > > pages are tracked precisely then there is no such problem. > > > > Ah, gotcha. Rather than let (and force) the user to provide a larger sleep > > time, > > what if we instead randomize the delay before the initial reaping of the > > dirty > > bitmap/ring? That should provide a good balance between coverage, > > complexity and > > user-friendliness. > > I'm fine with your solution, I applied it and it did trigger the same issue.
Awesome! I'll post a patch today.
