Initial take will just use the single threaded ftq for regression, we still need a regression script to organize results, but this should be relatively straightforward since all the version info is availabel in the #P device. Not clear how we get md5sum of the binary unfortunately, we can make certain assumptions based on surveyor. To keep things simple, we'll start with hardcoded version and then generalize.
bugs in lat_ctx may be timing related, potentially complicated by the virtual machine. Need to get criswell rebooted and try out there to make sure its not something stupid tripping things up. Be good to have ftq and 9bench numbers for a typical x86 machine to calibrate against anyways.
Nope FP errors happen on criswell as well, something is buggered in the timing code when the measurements are too small.
Okay, not a whole lot of progress today. Futz'd a bit with the lmbench code to see what works and what doesn't. It will be a nice set of numbers at the end of the day and we have the x86 code to compare against.
Since criswell is running the same hardware as the box next to it I should be able to get numbers for Plan 9 vesus Linux easily enough and we can use these as baselines for the normal Plan 9 regressions. We'll need to get the kittyhawk and/or zeptos code base running and try either lmbench or our modified versions there.
Of course, the thing I was suppose to be doing today was getting a top-level script together which runs on the desktop and initiates data collection (initially only of ftq) and stores results in a hierarchy based on kernel configuration (as read by '#P'/version and md5sum 9bgp.elf). I suppose I may still be able to pull those basics together this evening.
0 comments:
Post a Comment