VM suggestion...
While you guys are in there hacking, perhaps consider adding metrics which allows you to tell exactly when certain cases and conditions are hit.
page_aged_while_sleeping_in_page_lauder++
Statistics like this are cheap to use in runtime and should provide concrete information rather than guesses and estimations...
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Quoted 7 lines · Jeff Garzik
While you guys are in there hacking, perhaps consider adding metrics which allows you to tell exactly when certain cases and conditions are hit.
page_aged_while_sleeping_in_page_lauder++Statistics like this are cheap to use in runtime and should provide concrete information rather than guesses and estimations...
I've been using LTT (Linux Trace Toolkit) to do similar stuff.
The problem is that we _cannot_ base ourselves simply on practical results from a _limited_ amount of workloads. Also remember the tests we (at least I do) are benchmarks which try to use all resources all the time upon completion.
From: "Marcelo Tosatti" <[email protected]>
Quoted 4 lines
The problem is that we _cannot_ base ourselves simply on practical results from a _limited_ amount of workloads. Also remember the tests we (at least I do) are benchmarks which try to use all resources all the time upon completion.
Isn't this the point of the X.odd.Y kernels? Spit the stats out into the syslog, along with a message of "If you see these, please mail them along to [email protected] and a description of your workload if it's not too much trouble."
..Stu
Quoted 10 lines · Stuart MacDonald
From: "Marcelo Tosatti" <[email protected]>
Quoted 4 lines
The problem is that we _cannot_ base ourselves simply on practical results from a _limited_ amount of workloads. Also remember the tests we (at least I do) are benchmarks which try to use all resources all the time upon completion.
Isn't this the point of the X.odd.Y kernels? Spit the stats out into the syslog, along with a message of "If you see these, please mail them along to [email protected] and a description of your workload if it's not too much trouble."
First of all, s/[email protected]/[email protected]/.
That sounds interesting, yes. I'll look into that once I find sometime.
Thanks for your suggestion.
Quoted 5 lines · Marcelo Tosatti
Quoted 2 lines · Jeff Garzik
Statistics like this are cheap to use in runtime and should provide concrete information rather than guesses and estimations...
I've been using LTT (Linux Trace Toolkit) to do similar stuff.
But you can't expect everybody to use LTT. If you just make a couple of counters and give an easy way to get the values from userspace (proc, sysctl, syslog), you'll get bug reports with real information. IMHO data from real world workloads make more sense than "it doesn't work" reports.
Erik
Signature · 5 lines
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected] WWW: http://www-ict.its.tudelft.nl/~erik/
Quoted 5 lines · Erik Mouw
Quoted 4 lines · Marcelo Tosatti
Quoted 2 lines · Jeff Garzik
Statistics like this are cheap to use in runtime and should provide concrete information rather than guesses and estimations...
Quoted 7 lines
Quoted 1 line
I've been using LTT (Linux Trace Toolkit) to do similar stuff.
But you can't expect everybody to use LTT. If you just make a couple of counters and give an easy way to get the values from userspace (proc, sysctl, syslog), you'll get bug reports with real information. IMHO data from real world workloads make more sense than "it doesn't work" reports.
Agreed.
I'm looking forward to do something similar to what Paul Buder suggested, when I have time.