On Fri, Aug 20, 2010 at 04:16:09PM +0800, Michael Rubin wrote:

On Thu, Aug 19, 2010 at 7:51 PM, Wu Fengguang [off-list ref] wrote:

quoted

As Rik said, /proc/sys is not a suitable place.

OK I'm convinced.

quoted

Frankly speaking I've worked on writeback for years and never felt
the need to add these counters. What I often do is:

$ vmmon -d 1 nr_writeback nr_dirty nr_unstable

A  A  nr_writeback A  A  A  A  nr_dirty A  A  A nr_unstable
A  A  A  A  A  A 68738 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 39568
A  A  A  A  A  A 66051 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 42255
A  A  A  A  A  A 63406 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 44900
A  A  A  A  A  A 60643 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 47663
A  A  A  A  A  A 57954 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 50352
A  A  A  A  A  A 55264 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 53042
A  A  A  A  A  A 52592 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 55715
A  A  A  A  A  A 49922 A  A  A  A  A  A  A  A 0 A  A  A  A  A  A 58385
That is what I get when copying /dev/zero to NFS.

I'm very interested in Google's use case for this patch, and why
the simple /proc/vmstat based vmmon tool is not enough.

So as I understand it from looking at the code vmmon is sampling
nr_writeback, nr_dirty which are exported versions of
global_page_state for NR_FILE_DIRTY and NR_WRITEBACK. These states are
a snapshot of the state of the kernel's pages. Namely how many dpages
ar ein writeback or dirty at the moment vmmon's acquire routine is
called.

vmmon is sampling /proc/vstat and then displaying the difference from
the last time they sampled.  If I am misunderstanding let me know.

Maybe Andrew's vmmon does that. My vmmon always display the raw values
:) It could be improved to do raw values for nr_dirty and differences
for pgpgin by default.

This is good for the state of the system but as we compare
application, mm and io performance over long periods of time we are
interested in the surges and fluctuations of the rates of the
producing and consuming of dirty pages also. It can help isolate where
the problem is and also to compare performance between kernels and/or
applications.

Yeah the accumulated dirty and writeback page counts could be useful.
For example, for inspecting the dirty and writeback speed over time.
That's not possible for nr_dirty/nr_writeback.

Thanks,
Fengguang

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>