Dan Price wrote:
On Thu 18 Aug 2005 at 01:54AM, Phil Harman wrote:Dan,This is related to the undersized batch issue I mentioned in an earlier thread. From your data we can see that the batch (sample) size is 1. This is broken. It means that alternate batches will use PROT_NONE and PROT_READ | PROT_WRITE. I suspect one of these is cheap, and the other is not ... at least this would explain why you get two distinct timings with 50% of the samples in each.This is another instance of a change in libMicro exposing some interesting behaviour (which seems to deserve further investigation). But it also points to more work needing doing on the new duration control code in 0.3.0.Ok. Thanks. Is it reasonable to consider any 0.3.0 results valid in this case?
Good question. I really don't know. I'm only just getting up to speed on how Barts new control code behaves. My gut feel is that there should be a default batch size for each case (the goal being simply to amortise the call/loop overhead and to improve the timing resolution). I'm not sure it is possible to compare runs unless they have very similar batch sizes.
Is there a patch I can apply?
-dp
Not yet. Bart is on vacation, and I'm trying to steal some cycles to look at it. It may be that we'll need to take one or two steps back towards 0.2.19 before going forward again. We thank you for testing 0.3.0 for us :)
Phil
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
