Re: [PATCH 2/3] writeback: Adding pages_dirtied andpages_entered_writeback

[Wu Fengguang]

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@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/