I'll try to implement Drew's suggestion re: syncing global variables and then looking up CPU ID. If I can do that I'll upload another patch set for s390, aarch64, and x86. If I can't I'll move this test to the x86 subdirectory. I apologize for not responding to the comments on the previous version of this patch set. I'm still learning the mailing list etiquette. In the future is it preferable that I reply to those comments when I upload a new patch set addressing them, or should I add a note in the new patch emails about the comments I addressed in that update? I don't have any aarch64 or s390 hardware handy to test on so I'll try to move support for those architectures to separate commits at the end of the series, and mark them untested. Thank you for your quick responses! On Tue, Jan 7, 2020 at 6:56 AM Andrew Jones <drjones@xxxxxxxxxx> wrote: > > On Tue, Jan 07, 2020 at 09:33:34AM -0500, Peter Xu wrote: > > On Mon, Dec 16, 2019 at 01:38:54PM -0800, Ben Gardon wrote: > > > While userfaultfd, KVM's demand paging implementation, is not specific > > > to KVM, having a benchmark for its performance will be useful for > > > guiding performance improvements to KVM. As a first step towards creating > > > a userfaultfd demand paging test, create a simple memory access test, > > > based on dirty_log_test. > > > > > > Signed-off-by: Ben Gardon <bgardon@xxxxxxxxxx> > > > > It's fine to start with x86-only for this test, but imho it would be > > better to mention that in cover letter, or reply to reviewer comments > > on that you removed aarch64 from previous post. > > I'd also prefer that if it's x86-only that it be put in the x86_64 > subdirectory and drop the arch #ifdefs. The question is why is it > x86-only for now though? Will it take a lot of work to port it to > other architectures? Or does it just need testing by someone with > the hardware? > > Thanks, > drew >
