VM suggestion...

VM suggestion...

[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...

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: VM suggestion...

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Jeff Garzik wrote:

> 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.

Re: VM suggestion...

[Stuart MacDonald]

From: "Marcelo Tosatti" <marcelo@conectiva.com.br>
> 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 marcelo@conectiva.com.br and a description of your workload
if it's not too much trouble."

..Stu

Re: VM suggestion...

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Stuart MacDonald wrote:

> From: "Marcelo Tosatti" <marcelo@conectiva.com.br>
> > 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 marcelo@conectiva.com.br and a description of your workload
> if it's not too much trouble."

First of all, s/marcelo@conectiva.com.br/linux-mm@kvack.org/. 

That sounds interesting, yes. I'll look into that once I find sometime.

Thanks for your suggestion. 

Re: VM suggestion...

[Erik Mouw]

On Thu, Jun 07, 2001 at 04:36:05PM -0300, Marcelo Tosatti wrote:
> On Thu, 7 Jun 2001, Jeff Garzik wrote:
> > 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

-- 
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: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: VM suggestion...

[Marcelo Tosatti]

On Fri, 8 Jun 2001, Erik Mouw wrote:

> On Thu, Jun 07, 2001 at 04:36:05PM -0300, Marcelo Tosatti wrote:
> > On Thu, 7 Jun 2001, Jeff Garzik wrote:
> > > 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.

Agreed.

I'm looking forward to do something similar to what Paul Buder suggested,
when I have time. 

Re: VM suggestion...

[Martin.Knoblauch]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

>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... 

 after following the several [very entertaining/enlightening] threads on
VM [mis]behaviour, I wanted to ask a similar question: are there any
counters/statistics about the various buffers/caches in the VMS system,
that are easily available to userland? I know other Unix OSSes, where
you can get a lot of information about the efficiency of the subsystem.

Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Card for Martin.Knoblauch --]
[-- Type: text/x-vcard; charset=us-ascii; name="Martin.Knoblauch.vcf", Size: 375 bytes --]

begin:vcard 
n:Knoblauch;Martin
tel;cell:+49-170-4904759
tel;fax:+49-89-510857-111
tel;work:+49-89-510857-309
x-mozilla-html:FALSE
url:http://www.teraport.de
org:TeraPort GmbH;C+ITS
adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany
version:2.1
email;internet:Martin.Knoblauch@TeraPort.de
title:Senior System Engineer
x-mozilla-cpt:;-7008
fn:Martin Knoblauch
end:vcard