How many do you think is sufficient ?
I looked at my hand 2.4 million times and it was not wet each time.
Therefore, it is not raining.
Of course, if I am inside a roofed structure, the sampling is faulty.
And (correct me if I'm wrong here, Dave) I think that's what we're
asking about. Are the samples you're getting pertinent and
significant? If, as you suggested in another email, you disable
interrupts in the functions to take these measurements, you may be
significantly altering the very environment you hope to measure.
Why do you think oprofile is a better way to measure this ? BTW,
Mala works with Troy Wilson who is running SPECweb99 on an 8-way
system using Apache. Troy has run with Mala's patch and that data
will be posted.
That will be helpful. Microbenchmarks which measure cycles are far
less interesting to the community than the end results of actual
workloads. Note that Mala said "I measured the cycles for only the
initialization code in alloc_skb and __kfree_skb" which could mean that
even other parts of alloc_skb() or __kfree_skb() may have gotten worse
and you would not have known. Later she admits, "As the scope of the
code measured widens the percentage improvement comes down" and finally
observes "We measured it in a web serving workload and found that we
get 0.7% improvement" which is practically in the noise. Dave's
observation was that it was slightly worse (0.35%). Either could be
statistical noise. If the patch only creates statistical noise, the
community won't be interested.
Also, it is well known and widely recognized that more cpus add
increasing complexity with cache and code interactions. Have you
tested this on an 8-way machine, rather than a 2-way, and do the
results still hold? Things which look very good on 2-proc can start to
lose their lustre on 8-proc or bigger.
I'm unfamiliar with netperf -- does it yield "results" which can be
compared? If so, since it was used to generate the load, how did the
results of the two runs compare?
Rick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/