On Sat, 14 Jul 2001, Chris Wedgwood wrote:

On Fri, Jul 13, 2001 at 07:08:23PM -0300, Marcelo Tosatti wrote:

    With this data we are able to know more about what is really going
    on in the VM.

    +vm_pglaunder: nr of page_launder() calls 
    +vm_pglaunder_write: nr of times page_launder() started writting out data to free 
    +memory.
    +vm_refill_inactive_scan: nr of refill_inactive_scan() calls
    +vm_alloc_resched: nr of reschedule's in __alloc_pages() due to a memory shortage.
    +vm_kswapd_wakeup: nr of kswapd wakeup's 
    +vm_kreclaimd_wakeup: nr of kreclaimd wakeup's 
    +vm_kflushd_wakeup: nr of kflushd wakeup's 
    +
    +Per-zone statistics:
    +free shortage: per-zone free shortage
    +inactive shortage: per-zone inactive shortage
    +vm_launder_pgscan: number of pages scanned by page_launder
    +vm_pgclean: number of pages cleaned (moved to the inactive clean list) by page_launder
    +vm_pgskiplocked: number of locked pages skipped by page_launder
    +vm_pgskipdirty: number of dirty pages skipped by page_launder
    +vm_pglaundered: laundered pages by page_launder
    +vm_pgreact: pages reactivated in page_launder
    +vm_pgrescue: pages rescue in reclaim_page
    +vm_pgagescan: pages scanned by refill_inactive_scan()
    +vm_pgagedown: pages aged down by refill_inative_scan()
    +vm_pgageup: pages aged up by refill_inactive_scan()/try_to_swap_out()
    +vm_pgdeact: deactivated pages by deactivate_page
    +vm_pgdeactfail_age: nr of deactivation failures on refill_inactive_scan() 
    +due to >0 age
    +vm_pgdeactfail_ref: nr of deactivation failures on refill_inactive_scan()
    +due to zero aged pages with more users than the pagecache
    +vm_reclaimfail: failures of reclaim_page() (no freeable clean pages in the inactive
    +clean list for this zone)
    +vm_ptescan: nr of present ptes scanned by swap_out()
    +vm_pteunmap: nr of present ptes unmapped by swap_out()

Some of these seem very specialised and low-level.

Yes they are.

Perhaps another /proc entry might be a better idea along with either a
different vmstat, 

Maybe. Personally I don't really care about the way we are doing this, as
long as I can get the information. I can add /proc/vmstat easily if
needed...

Linus, how do you want this thing done to be accepted in the stock tree? 

or changes to vmstat such that it will behave as always if not given a
magic command line switch and/or this new /proc entry isn't present?

Well, I don't want to include this stuff on the stock vmstat code right
now. I've done an ugly hack in vmstat.c to get the thing to work and thats
it.

I will keep an updated version of the "hacked" vmstat.c on my homepage
until I find time/balls to code something which does not stink. 

Right now, much of what comes form vmstat vaguley resembles other OSs,
with the above, it will be very different.

Indeed.

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