Re: The long, long life of an inactive_dirty page

[Arjan van de Ven <arjanv@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

On Wed, 2004-05-12 at 20:24, Andrew Crawford wrote:
> Thanks for all your replies so far, and the helpful information.
> 
> > well you may IF you fix  your mail setup to not send me evil mails about
> > having to confirm something.
> 
> Just to clarify, you received that mail because you replied to this address
> directly; This account don't accept emails from unverified addresses. This
> account is not subscribed to linux-mm, which I read elsewhere.

I find that truely obnoxious.

> > One thing to realize is that after bdflush has written the pages out, they
> > can become dirty AGAIN for a variety of reasons, and as such the accounting
> > is not quite straightforward.
> 
> Is it possible for a page to become dirty again while still remaining
> inactive? Could you give an example? (genuinely curious, hope this doesn't
> sound like I'm arguing!)

If someone has that page mmaped for example, the app that has it mmap'd
can just write to the memory (which makes the page dirty in the
pagetable). The kernel doesn't get involved in that at all.


> > the problem is that the "becoming clean" is basically asynchronous
> 
> Isn't this equally true for page_launder? Even if bdflush would wait until the
> next "pass" to move pages to the "clean" list it would be better than the
> current situation. There must be some mechanism that bdflush uses to avoid
> writing the same page twice in a row; couldn't it say "oh, already wrote that
> one, into inactive_clean it goes".

It's slightly more subtle in the kernel you looked at. There is a list
for "write out pending" and a "clean" list.
Between all these lists there is a strict LRU order. You don't move it
to clean once it gets clean, you move it to "write out pending" when you
start writeout, and the VM moves the *other* side of the writeout list
to the clean list when it's clean.


> You will probably appreciate that I am coming at this from the point of view
> of performance measurement and capacity planning; I want to know how much
> actual memory is free or immediately reusable at a point in time.

That information is not achievable in a reliable way, ever. Simply
because it takes a not-even-near-inifintely small amount of time to
gather all the stats, during which the other cpu can change all the
underlying data away under your nose.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]