Re: The long, long life of an inactive_dirty page

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

[-- 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 --]