On Tue, Dec 19, 2017 at 02:07:06PM +0100, Christoffer Dall wrote: > On Tue, Dec 19, 2017 at 01:11:09PM +0100, Andrew Jones wrote: > > On Tue, Dec 19, 2017 at 10:06:20AM +0100, Christoffer Dall wrote: > > > On Mon, Dec 18, 2017 at 03:58:49PM -0500, Shih-Wei Li wrote: > > > > > > > > I have only tested the code by invoking test directly using make > > > > standalone like the following. I did notice that it took ~90 seconds > > > > to finish the test itself. > > > > ./"tests/micro-cost" > > > > standalone still uses timeout with 90 seconds. So your hardware was just > > faster than mine, I guess :-) > > > > [indentation confusion?] Actually I was just lazily replying to both you and Shih-Wei in the same mail. > > You're responding to something Shih-Wei wrote here, but I didn't > understand Shih-Wei's answer, and I think he ran the work on Seattle, so > not sure what the difference was. It turns out the problem was just the opposite of what I say above. My hardware must be faster. While testing v2 of the patch I still got timeouts, so I decided to actually try to figure out what's going on. The eoi_test() test is so fast that c1 always equals c2, so we always assume an overflow occurred and keep trying to get a better sample. I guess we need two changes to the patch. We need to handle c1 == c2 differently, probably just assume the measurement is smaller than the timer frequency and report 1 tick instead of zero. We should also have a way out of loop_test() when the test is constantly returning zero. Thanks, drew _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
