Messages in this thread | | | From | Joonsoo Kim <> | Date | Tue, 17 Mar 2020 13:52:40 +0900 | Subject | Re: [PATCH v2 2/9] mm/vmscan: protect the workingset on anonymous LRU |
| |
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.
| |