linux-kernel - Re: mm: dirty page problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <fc71709d0906230632qefb072bj5ea7597b20972aa3@mail.gmail.com>
Date:	Tue, 23 Jun 2009 21:32:33 +0800
From:	xue yong <ultraice.kernel@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: mm: dirty page problem

On Tue, Jun 23, 2009 at 7:52 PM, Peter Zijlstra<peterz@...radead.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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/