lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimKn5BZiCAyr-3XAZuu66Q+ASZgBZ7LDU2Jom1p@mail.gmail.com>
Date:	Fri, 20 Aug 2010 01:16:09 -0700
From:	Michael Rubin <mrubin@...gle.com>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, jack@...e.cz, riel@...hat.com,
	akpm@...ux-foundation.org, david@...morbit.com, npiggin@...e.de,
	hch@....de, axboe@...nel.dk
Subject: Re: [PATCH 2/3] writeback: Adding pages_dirtied and pages_entered_writeback

On Thu, Aug 19, 2010 at 7:51 PM, Wu Fengguang <fengguang.wu@...el.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.

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.

mrubin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ