Re: [PATCH 2/3] writeback: Adding pages_dirtied and pages_entered_writeback

[Wu Fengguang <fengguang.wu@intel.com>]

On Fri, Aug 20, 2010 at 04:16:09PM +0800, Michael Rubin wrote:
> On Thu, Aug 19, 2010 at 7:51 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > As Rik said, /proc/sys is not a suitable place.
> 
> OK I'm convinced.
> 
> > 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
> >
> >     nr_writeback         nr_dirty      nr_unstable
> >            68738                0            39568
> >            66051                0            42255
> >            63406                0            44900
> >            60643                0            47663
> >            57954                0            50352
> >            55264                0            53042
> >            52592                0            55715
> >            49922                0            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