On Tue, Mar 14, 2006 at 03:49:16PM -0500, Shailabh Nagar wrote:I guess you meant a), not b) but yes, will run them in all these modes.
Greg KH wrote:
On Mon, Mar 13, 2006 at 07:40:34PM -0500, Shailabh Nagar wrote:None yet. Wanted to iron out the collection/utility aspects a bit before going into
This is the next iteration of the delay accounting patchesDo you have any benchmark numbers with this patch applied and with it
last posted at
http://www.ussg.iu.edu/hypermail/linux/kernel/0602.3/0893.html
not applied?
the performance impact.
But this seems as good a time as any to collect some stats
using the usual suspects lmbench, kernbench, hackbench etc.
Last I heard it was a measurable decrease for someMight have been from an older iteration where schedstats was fully enabled.
"important" benchmark results...
But no point speculating....will run with this set of patches and see what shakes out.
One point about the overhead is that it depends on the frequency with which data is
collected. So a proper test would probably be a comparison of a non-patched kernel
with
a) patches applied but delay accounting not turned on at boot i.e. cost of the checks
b) delay accounting turned on but not being read
This is probably the most important one, as that is what distros will be
looking at. They will have to enable the option, but will not "turn it
on".
Hmm...though you also know, from working for some "big company", that it might
c) delay accounting turned on and data read for all tasks at some "reasonable" rate
Will that be good ? Other suggestions welcome.
How about real benchmarks? The ones that the big companies look at? I
know you have access to them :)
thanks,
greg k-h