Re: 2.6.xx: dirty pages never being sync'd to disk?

[Badari Pulavarty <pbadari@gmail.com>]

On Mon, 2005-11-14 at 10:49 -0500, Mark Lord wrote:
> Arjan van de Ven wrote:
> > On Mon, 2005-11-14 at 10:30 -0500, Mark Lord wrote:
> ..
> >>My Notebook computer has 2GB of RAM, and the 2.6.xx kernel seems quite
> >>happy to leave hundreds of MB of dirty unsync'd pages laying around
> ..
> >>/proc/sys/vm/dirty_expire_centisecs = 3000 (30 seconds)
> >>/proc/sys/vm/dirty_writeback_centisecs = 500 (5 seconds)
> ..
> > do you have laptop mode enabled? That changes the behavior bigtime in
> > this regard and makes the kernel behave quite different.
> 
> No.  Laptop-mode mostly just modifies the dirty_expire
> and related settings, and I have them set as shown above.
> But there's also this:
> 
> /proc/sys/vm/laptop_mode = 0
> 
> > also if these are files written to by mmap, the kernel only really sees
> > those as dirty when the mapping gets taken down
> 
> They certainly show up in the counts in /proc/meminfo under "Dirty",
> so I assumed that means the kernel knows they are dirty.
> 
> A simple test I do for this:
> 
> $ mkdir t
> $ cp /usr/src/*.bz2  t    (about 400-500MB worth of kernel tar files)
> 
> In another window, I do this:
> 
> $ while (sleep 1); do echo -n "`date`: "; grep Dirty /proc/meminfo; done
> 
> And then watch the count get large, but take virtually forever
> to count back down to a "safe" value.
> 
> Typing "sync" causes all the Dirty pages to immediately be flushed to disk,
> as expected.
> 
> Here's what the monitoring of /proc/meminfo shows,
> on an otherwise mostly idle system after having done
> the big file copies noted earlier:
> 
> Mon Nov 14 10:40:22 EST 2005: Dirty:          481284 kB
> Mon Nov 14 10:40:23 EST 2005: Dirty:          479680 kB


Interesting. Since you have a very easy to reproduce case -
can you write a program to do posix_fadvise(POSIX_FADV_DONTNEED)
on those files in directory "t" and see what happens ?

Thanks,
Badari