lkml.org 
[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: mm: dirty page problem
From
Date
On Tue, 2009-06-23 at 21:32 +0800, xue yong wrote:
> 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.

I'm one of the people who knows this code rather well, yes ;-)

> 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.

While a great book to learn some of the basics from, it is severely
out-dated. I think in his 2.6 chapter he does mention something about
reverse map, or rmap as its called.

These days we do keep a data structure whereby it is easier to find all
ptes for a particular mapping (mm/rmap.c).

In particular try_to_unmap() is the routine used to remove all ptes in
order to swap a page.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-06-23 15:41    [W:0.035 / U:1.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site