Re: [PATCH v2 2/9] mm/vmscan: protect the workingset on anonymous LRU

[Joonsoo Kim <js1304@gmail.com>]

2020년 3월 17일 (화) 오전 1:12, Johannes Weiner <hannes@cmpxchg.org>님이 작성:
>
> On Mon, Mar 16, 2020 at 04:05:30PM +0900, Joonsoo Kim wrote:
> > 2020년 3월 14일 (토) 오전 4:55, Johannes Weiner <hannes@cmpxchg.org>님이 작성:
> > > The problem with executables is that when they are referenced, they
> > > get a *lot* of references compared to data pages. Think about an
> > > instruction stream and how many of those instructions result in data
> > > references. So when you see an executable page that is being accessed,
> > > it's likely being accessed at a high rate. They're much hotter, and
> > > that's why reference bits from VM_EXEC mappings carry more weight.
> >
> > Sound reasonable.
> >
> > But, now, I have another thought about it. I think that the root of the reason
> > of this check is that there are two different reference tracking models
> > on file LRU. If we assume that all file pages are mapped ones, this special
> > check isn't needed. If executable pages are accessed more frequently than
> > others, reference can be found more for them at LRU cycle. No need for this
> > special check.
> >
> > However, file pages includes syscall-ed pages and mapped pages, and,
> > reference tracking models for mapped page has a disadvantage to
> > one for syscall-ed page. Several references for mapped page would be
> > considered as one at LRU cycle. I think that this check is to mitigate
> > this disadvantage, at least, for executable file mapped page.
>
> Hm, I don't quite understand this reasoning. Yes, there are two models
> for unmapped and mapped file pages. But both types of pages get
> activated with two or more references: for unmapped it's tracked
> through mark_page_accessed(), and for mapped it's the two LRU cycles
> with the referenced bit set (unmapped pages don't get that extra trip
> around the LRU with one reference). With that alone, mapped pages and
> unmapped pages should have equal chances, no?
>

Think about following example.

Assume that the size of inactive list for file page is 100.

1. start the new page, A, and access to A happens
2. 50 inactive pages are reclaimed due to 50 new pages
3. second access to A happens
4. 50 inactive pages are reclaimed due to 50 new pages
5. 100 inactive pages are reclaimed due to 100 new pages

If A is:
unmapped page: the page is activated at #3 and lives after #5
mapped page: the page reference is checked at #4 and re-attached
to the inactive list with PageReferenced() but is eventually reclaimed at #5

Even they are referenced by the same pattern, mapped page is reclaimed
but unmapped isn't. This is, what I said before, the disadvantage of
the mapped page than unmapped page. My guess is that to mitigate this
disadvantage on mapped file page, VM_EXEC test is needed since
VM_EXEC is the most important case for mapped file page.

Thanks.