Re: The long, long life of an inactive_dirty page

Arjan van de Ven
2004-05-12T14:51:50Z

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

> It is my understanding that the next thing that should happen is that
> page_launder(), which is invoked when memory gets low, should come along and
> get those pages written, and then, on its next pass mark them inactive_clean.
>
> But in thise case, we have plenty of memory available and absolutely nothing
> using it. So there's never any memory pressure, page_launder is never called,
> and the data is never written to disk. This is arguably a bad thing; an
> entirely idle system should not be sitting for hours or days with uncommitted
> data in RAM for the obvious reason.

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.

> > grep Inact_dirty /proc/meminfo
> Inact_dirty: 492240 kB
>
> [ ~5 minutes later ]
>
> > grep Inact_dirty /proc/meminfo
> Inact_dirty: 463680 kB

Inact_dirty isn't guaranteed to be dirty, it's the list of pages that
CAN be dirty.

> That's 460MB of uncommitted data hanging around on a completely idle machine.
>
it's not uncommitted, as I said there are other methods that make sure
that doesn't happen.

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