[RFC] VM statistics to gather

[RFC] VM statistics to gather

[Rik van Riel]

Hi,

I am starting the process of adding more detailed instrumentation
to the VM subsystem and am wondering which statistics to add.
A quick start of things to measure are below, but I've probably
missed some things. Comments are welcome ...



--- kernel_stat.h.instr	Sun Jun 24 19:52:34 2001
+++ kernel_stat.h	Mon Jun 25 20:02:38 2001
@@ -26,6 +26,25 @@
 	unsigned int dk_drive_wblk[DK_MAX_MAJOR][DK_MAX_DISK];
 	unsigned int pgpgin, pgpgout;
 	unsigned int pswpin, pswpout;
+	unsigned int vm_pgscan;		/* Pages scanned by pageout code. */
+	unsigned int vm_pgdeact;	/* Pages deactivated by pageout code */
+	unsigned int vm_pgclean;	/* Pages moved to inactive_clean */
+	unsigned int vm_pgskiplaunder;	/* Pages skipped by page_launder */
+	unsigned int vm_pglaundered;	/* Pages laundered by page_launder */
+	unsigned int vm_pgreact;	/* Pages reactivated by page_launder
+					 * (rescued from inactive_clean list) */
+	unsigned int vm_pgrescue;	/* Pages reactivated by reclaim_page
+					 * (rescued from inactive_dirty list) */
+	unsigned int vm_majfault;	/* Major page faults (disk IO) */
+	unsigned int vm_minfault;	/* Minor page faults (no disk IO) */
+	unsigned int vm_cow_fault;	/* COW faults, copy needed */
+	unsigned int vm_cow_optim;	/* COW skipped copy */
+	unsigned int vm_zero_fault;	/* Zero-filled page given to process */
+	unsigned int vm_zero_optim;	/* COW of the EMPTY_ZERO_PAGE */
+	unsigned int vm_kswapd_wakeup;	/* kswapd wake-ups */
+	unsigned int vm_kswapd_loops;	/* kswapd go-arounds in kswapd() loop */
+	unsigned int vm_pg_freed;	/* Pages freed by pageout code, also
+					   pages moved to inactive_clean */
 #if !defined(CONFIG_ARCH_S390)
 	unsigned int irqs[NR_CPUS][NR_IRQS];
 #endif

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Roger Larsson]

Hi,

What about

   unsigned int vm_pgfails /* failed alloc attempts, in pages (not calls) */

maybe even a

   unsigned int vm_pgallocs /* alloc attempts, in pages */

for sanity checking - should be the sum of several other combinations...

Should memory zone be used as dimension?


/RogerL


-- 
Roger Larsson
Skelleftea
Sweden

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Rik van Riel]

On Tue, 26 Jun 2001, Roger Larsson wrote:

> What about
>
>    unsigned int vm_pgfails /* failed alloc attempts, in pages (not calls) */

What would that represent ?

How often __alloc_pages() exits without allocating anything?

> maybe even a
>
>    unsigned int vm_pgallocs /* alloc attempts, in pages */
>
> for sanity checking - should be the sum of several other combinations...

Sounds like a nice idea.

> Should memory zone be used as dimension?

Useful for allocations I guess, but it may be too confusing
if we do this for all statistics... OTOH...

Comments, anyone?

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Roger Larsson]

On Tuesday 26 June 2001 01:59, Rik van Riel wrote:
> On Tue, 26 Jun 2001, Roger Larsson wrote:
> > What about
> >
> >    unsigned int vm_pgfails /* failed alloc attempts, in pages (not calls)
> > */
>
> What would that represent ?
>
> How often __alloc_pages() exits without allocating anything?

Yes, failed allocs  [Call it vm_pgalloc_fails ?]

>
> > maybe even a
> >
> >    unsigned int vm_pgallocs /* alloc attempts, in pages */
> >
> > for sanity checking - should be the sum of several other combinations...
>
> Sounds like a nice idea.
>

Let this and vm_pgalloc_fails work together,

at __alloc_pages entry (always done) account in vm_pgallocs
at failed exit account in vm_pgallocs_failed

> > Should memory zone be used as dimension?
>
> Useful for allocations I guess, but it may be too confusing
> if we do this for all statistics... OTOH...

Using order as another dimension could also be interesting...
Something like this?

vm_pgallocs[
	order < MAX_ACCOUNT_ORDER ? order : MAX_ACCOUNT_ORDER][
	gfp_mask & GFP_ZONEMASK] += (1 << order)

Or even simpler (assuming MAX_ACCOUNT_ORDER == 1)

vm_pgallocs[!!order][gfp_mask & GFP_ZONEMASK] += (1 << order)

BTW, why is GFP_ZONEMASK 0xf when MAX_NR_ZONES is 3 ? (i.e. 0..2)

/RogerL

-- 
Roger Larsson
Skelleftea
Sweden
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Stephen C. Tweedie]

Hi,

On Mon, Jun 25, 2001 at 08:59:11PM -0300, Rik van Riel wrote:

> > Should memory zone be used as dimension?
> 
> Useful for allocations I guess, but it may be too confusing
> if we do this for all statistics... OTOH...

Then user space monitor apps can summarise over all zones.

Rik, having this information available per-zone is critically
important for doing VM tuning.  Whenever we see VM lockups, being able
to deduce when we're spinning on a single zone will be enormously
helpful.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Marcelo Tosatti]

On Mon, 25 Jun 2001, Rik van Riel wrote:

> Hi,
> 
> I am starting the process of adding more detailed instrumentation
> to the VM subsystem and am wondering which statistics to add.
> A quick start of things to measure are below, but I've probably
> missed some things. Comments are welcome ...
> 
> 
> 
> --- kernel_stat.h.instr	Sun Jun 24 19:52:34 2001
> +++ kernel_stat.h	Mon Jun 25 20:02:38 2001
> @@ -26,6 +26,25 @@
>  	unsigned int dk_drive_wblk[DK_MAX_MAJOR][DK_MAX_DISK];
>  	unsigned int pgpgin, pgpgout;
>  	unsigned int pswpin, pswpout;
> +	unsigned int vm_pgscan;		/* Pages scanned by pageout code. */
> +	unsigned int vm_pgdeact;	/* Pages deactivated by pageout code */

s/page out code/deactivation code/ ?

+      unsigned int vm_swapout_pgdeact; /* Pages deactivated directly by
					  swapout() */

> +	unsigned int vm_pgclean;	/* Pages moved to inactive_clean */
> +	unsigned int vm_pgskiplaunder;	/* Pages skipped by page_launder */
> +	unsigned int vm_pglaundered;	/* Pages laundered by page_launder */
> +	unsigned int vm_pgreact;	/* Pages reactivated by page_launder
> +					 * (rescued from inactive_clean list) */

The "(rescued from inactive_clean list)" affirmation is not always true.

> +	unsigned int vm_pgrescue;	/* Pages reactivated by reclaim_page
> +					 * (rescued from inactive_dirty list) */
  	unsigned int vm_reclaimfail;	/* page_reclaim() failures (not able
					   to find any freeable page at 
					   inactive clean */
					
> +	unsigned int vm_majfault;	/* Major page faults (disk IO) */
> +	unsigned int vm_minfault;	/* Minor page faults (no disk IO) */
> +	unsigned int vm_cow_fault;	/* COW faults, copy needed */
> +	unsigned int vm_cow_optim;	/* COW skipped copy */
> +	unsigned int vm_zero_fault;	/* Zero-filled page given to process */
> +	unsigned int vm_zero_optim;	/* COW of the EMPTY_ZERO_PAGE */
> +	unsigned int vm_kswapd_wakeup;	/* kswapd wake-ups */
> +	unsigned int vm_kswapd_loops;	/* kswapd go-arounds in kswapd() loop */
	unsigned int vm_kreclaim_wakeup; /* kreclaimd wakeups */

> +	unsigned int vm_pg_freed;	/* Pages freed by pageout code, also
> +					   pages moved to inactive_clean */
>  #if !defined(CONFIG_ARCH_S390)
>  	unsigned int irqs[NR_CPUS][NR_IRQS];
>  #endif

Maybe I remember something more later..

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Marcelo Tosatti]

On Mon, 25 Jun 2001, Marcelo Tosatti wrote:

> 
> On Mon, 25 Jun 2001, Rik van Riel wrote:
> 
> > Hi,
> > 
> > I am starting the process of adding more detailed instrumentation
> > to the VM subsystem and am wondering which statistics to add.
> > A quick start of things to measure are below, but I've probably
> > missed some things. Comments are welcome ...

	unsigned int vm_agepagedown; /* Count of age page down */
	unsigned int vm_agepageup;   /* Count of age page up */ 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Andrew Morton]

Rik van Riel wrote:
> 
> Hi,
> 
> I am starting the process of adding more detailed instrumentation
> to the VM subsystem and am wondering which statistics to add.
> A quick start of things to measure are below, but I've probably
> missed some things. Comments are welcome ...

Neat.

- bdflush wakeups
- pages written via page_launder's writepage by kswapd
- pages written via page_launder's writepage by non-PF_MEMALLOC
  tasks.  (ext3 has an interest in this because of nasty cross-fs
  reentrancy and journal overflow problems with writepage)
- shrink_icache call rate
- amount of stuff freed by shrink_icache
- ditto for shrink_dcache.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Marcelo Tosatti]

On Tue, 26 Jun 2001, Andrew Morton wrote:

> Rik van Riel wrote:
> > 
> > Hi,
> > 
> > I am starting the process of adding more detailed instrumentation
> > to the VM subsystem and am wondering which statistics to add.
> > A quick start of things to measure are below, but I've probably
> > missed some things. Comments are welcome ...
> 
> Neat.
> 
> - bdflush wakeups
> - pages written via page_launder's writepage by kswapd
> - pages written via page_launder's writepage by non-PF_MEMALLOC
>   tasks.  (ext3 has an interest in this because of nasty cross-fs
>   reentrancy and journal overflow problems with writepage)

Does ext3 call page_launder() with __GFP_IO ? 

If it does not (which I believe so), page_launder() without PF_MEMALLOC
never happens. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Marcelo Tosatti]

On Tue, 26 Jun 2001, Marcelo Tosatti wrote:

> 
> On Tue, 26 Jun 2001, Andrew Morton wrote:
> 
> > Rik van Riel wrote:
> > > 
> > > Hi,
> > > 
> > > I am starting the process of adding more detailed instrumentation
> > > to the VM subsystem and am wondering which statistics to add.
> > > A quick start of things to measure are below, but I've probably
> > > missed some things. Comments are welcome ...
> > 
> > Neat.
> > 
> > - bdflush wakeups
> > - pages written via page_launder's writepage by kswapd
> > - pages written via page_launder's writepage by non-PF_MEMALLOC
> >   tasks.  (ext3 has an interest in this because of nasty cross-fs
> >   reentrancy and journal overflow problems with writepage)
> 
> Does ext3 call page_launder() with __GFP_IO ? 
> 
> If it does not (which I believe so), page_launder() without PF_MEMALLOC
> never happens. 

s/page_launder()/page_launder() without PF_MEMALLOC/ 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Andrew Morton]

Marcelo Tosatti wrote:
> 
> On Tue, 26 Jun 2001, Andrew Morton wrote:
> 
> > Rik van Riel wrote:
> > >
> > > Hi,
> > >
> > > I am starting the process of adding more detailed instrumentation
> > > to the VM subsystem and am wondering which statistics to add.
> > > A quick start of things to measure are below, but I've probably
> > > missed some things. Comments are welcome ...
> >
> > Neat.
> >
> > - bdflush wakeups
> > - pages written via page_launder's writepage by kswapd
> > - pages written via page_launder's writepage by non-PF_MEMALLOC
> >   tasks.  (ext3 has an interest in this because of nasty cross-fs
> >   reentrancy and journal overflow problems with writepage)
> 
> Does ext3 call page_launder() with __GFP_IO ?
> 
> If it does not (which I believe so), page_launder() without PF_MEMALLOC
> never happens.

OK, I was using PF_MEMALLOC as shorthand for `kswapd', with
unsuccessful accuracy.  I think it's OK to block non-kswapd
tasks in writepage() while we open a new transaction, but it's
perhaps not so good to block kswapd there.

At present, if the caller is PF_MEMALLOC we make a non-blocking
attempt to open a transaction handle.  If it fails, redirty the
page and return.  It usually succeeds.  This may be excessively
paranoid.

I haven't played with it a lot recently, but it may turn out to
be useful to know whether the caller is kswapd or someone else,
and it'd be nice to know the calling context by means other than
inferring it from PF_MEMALLOC.  What happened to the writepage
`priority' patch you had, BTW?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [RFC] VM statistics to gather

[Marcelo Tosatti]

On Tue, 26 Jun 2001, Andrew Morton wrote:

> Marcelo Tosatti wrote:
> > 
> > On Tue, 26 Jun 2001, Andrew Morton wrote:
> > 
> > > Rik van Riel wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am starting the process of adding more detailed instrumentation
> > > > to the VM subsystem and am wondering which statistics to add.
> > > > A quick start of things to measure are below, but I've probably
> > > > missed some things. Comments are welcome ...
> > >
> > > Neat.
> > >
> > > - bdflush wakeups
> > > - pages written via page_launder's writepage by kswapd
> > > - pages written via page_launder's writepage by non-PF_MEMALLOC
> > >   tasks.  (ext3 has an interest in this because of nasty cross-fs
> > >   reentrancy and journal overflow problems with writepage)
> > 
> > Does ext3 call page_launder() with __GFP_IO ?
> > 
> > If it does not (which I believe so), page_launder() without PF_MEMALLOC
> > never happens.
> 
> OK, I was using PF_MEMALLOC as shorthand for `kswapd', with
> unsuccessful accuracy.  I think it's OK to block non-kswapd
> tasks in writepage() while we open a new transaction, but it's
> perhaps not so good to block kswapd there.
> 
> At present, if the caller is PF_MEMALLOC we make a non-blocking
> attempt to open a transaction handle.  If it fails, redirty the
> page and return.  It usually succeeds.  This may be excessively
> paranoid.
> 
> I haven't played with it a lot recently, but it may turn out to
> be useful to know whether the caller is kswapd or someone else,
> and it'd be nice to know the calling context by means other than
> inferring it from PF_MEMALLOC.  What happened to the writepage
> `priority' patch you had, BTW?

Not going to be included in 2.4, at first. (we "fixed" the dead swap cache
problem in other way)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/