Re: mm: dirty page problem

[xue yong <ultraice.kernel@gmail.com>]

On Tue, Jun 23, 2009 at 7:52 PM, Peter Zijlstra<peterz@infradead.org> wrote:
> On Tue, 2009-06-23 at 19:43 +0800, xue yong wrote:
>> Thanks a lot, Peter.
>> Your reply resolved my doubt.
>>
>> we have a service program (just say A) running with about 14G mmaped data.
>> and there is another daemon (just say B) do msync( SYNC) periodically.
>>
>> so I want to know in this pattern, was the data flushed to disk?
>
> I don't think so.
>
> The problem is that msync() only scans the current process' page tables,
> which would be clean since B doesn't write, only A does.
>
> So you'd have to modify your program, A, to do the msync() itself --
> possibly from a thread (threads share the vm context and thus page
> tables).
>


:)  I did have this thought, because there was littile bo(block out),
and pmap showed that
the dirty pages belong to a process was always growing.

I believe you are the authority. Your confirmation matters.

In "Understanding the Linux® Virtual Memory Manager" page 163, Mel
Gorman said that
Process-mapped pages are not easily swappable because there is no
way to map struct pages to PTEs except to search every page table, which is far
too expensive.
So  neither kswapd nor other kernel daemons do the scan job.
Without explicit action these pages would stay hidden.



>> and we have the problem,  after we stoped/restarted  A,  many ditry
>> pages emerged,
>> about 4G data was flushed out in the following time.
>>
>> Thanks for your advice on these patches. I understand it now.
>> So if we change the kernel to a higher version, can we solve the
>> problem I mentioned above.
>
> Yes, I would recommend running a more recent kernel.
>