Re: The long, long life of an inactive_dirty page

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

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

On Wed, 2004-05-12 at 17:28, Andrew Crawford wrote:
> Arjan van de Ven wrote:
> 
> >bdflush and co WILL commit the data to disk after like 30 seconds.
> >They will not move it to inactive_clean; that will happen at the first
> >sight of memory pressure. The code that does that notices that the data
> >isn't dirty and won't do a write-out just a move.
> 
> Thanks for that. I have a couple of follow-up questions if I may be so bold:

well you may IF you fix  your mail setup to not send me evil mails about
having to confirm something.

> 
> 1. Is there any way, from user space, to distinguish inactive_dirty pages
> which have actually been written from those which haven't?

no, in fact the kernel doesn't know until it looks at the pages (which
it only does on demand). 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.


> 2. Is there any reason, conceptually, that bdflush shouldn't move the pages to
> the inactive_clean list as page_launder does? After all, they become "known
> clean" at that point, not X hours later when there is a memory shortfall.

the problem is that the "becoming clean" is basically asynchronous,
which would mean the LRU order (FIFO basically) would be destroyed.
(there's implementation issues as well wrt lock ranking etc etc but
that's details)

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