Better active/inactive list balancing

Hi Johannes,

http://lwn.net/Articles/495543/

This link said that "When active pages are considered for eviction, they are first moved to the inactive list and unmapped from the address space of the process(es) using them. Thus, once a page moves to the inactive list, any attempt to reference it will generate a page fault; this "soft fault" will cause the page to be removed back to the active list."

Why I can't find the codes unmap during page moved from active list to inactive list?

cc linux-mm

Quoted 13 lines · Mtrr Patt

Hi Johannes,

http://lwn.net/Articles/495543/

This link said that "When active pages are considered for eviction, they are first moved to the inactive list and unmapped from the address space of the process(es) using them. Thus, once a page moves to the inactive list, any attempt to reference it will generate a page fault; this "soft fault" will cause the page to be removed back to the active list."

Why I can't find the codes unmap during page moved from active list to inactive list?

Quoted 14 lines · Mtrr Patt

cc linux-mm

Quoted 11 lines · Mtrr Patt

Hi Johannes,

http://lwn.net/Articles/495543/

This link said that "When active pages are considered for eviction, they are first moved to the inactive list and unmapped from the address space of the process(es) using them. Thus, once a page moves to the inactive list, any attempt to reference it will generate a page fault; this "soft fault" will cause the page to be removed back to the active list."

Quoted 2 lines

Quoted 2 lines

Why I can't find the codes unmap during page moved from active list to inactive list?

Most architectures have the hardware track the referenced bit in the page tables, but some don't. For them, page_referenced_one() will mark the mapping read-only when clearing the referenced/young bit and the page fault handler will set the bit manually.

When mapped pages reach the end of the inactive list and have that bit set, they get activated, see page_check_references().

Hi Johannes,

Quoted 17 lines · Johannes Weiner

Quoted 16 lines · Mtrr Patt

cc linux-mm

Quoted 13 lines · Mtrr Patt

Hi Johannes,

http://lwn.net/Articles/495543/

This link said that "When active pages are considered for eviction, they are first moved to the inactive list and unmapped from the address space of the process(es) using them. Thus, once a page moves to the inactive list, any attempt to reference it will generate a page fault; this "soft fault" will cause the page to be removed back to the active list."

Why I can't find the codes unmap during page moved from active list to inactive list?

Quoted 4 lines

Most architectures have the hardware track the referenced bit in the page tables, but some don't. For them, page_referenced_one() will mark the mapping read-only when clearing the referenced/young bit and the page fault handler will set the bit manually.

Thanks for your response. ;-) So the article is not against more common case, isn't it?

Quoted 2 lines

When mapped pages reach the end of the inactive list and have that bit set, they get activated, see page_check_references().

It seems that the page should trigger page fault twice and page_check_references can active it.

Hi Wanpeng Li / Ni zhan Chen / Jaegeuk Hanse / Simon Jeons / Will Huck / Ric Mason / Sam Ben / Mtrr Patt!

Quoted 17 lines · Mtrr Patt

Hi Johannes,

Quoted 15 lines · Johannes Weiner

Quoted 14 lines · Mtrr Patt

cc linux-mm

Quoted 11 lines · Mtrr Patt

Hi Johannes,

http://lwn.net/Articles/495543/

This link said that "When active pages are considered for eviction, they are first moved to the inactive list and unmapped from the address space of the process(es) using them. Thus, once a page moves to the inactive list, any attempt to reference it will generate a page fault; this "soft fault" will cause the page to be removed back to the active list."

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

Why I can't find the codes unmap during page moved from active list to inactive list?

Most architectures have the hardware track the referenced bit in the page tables, but some don't. For them, page_referenced_one() will mark the mapping read-only when clearing the referenced/young bit and the page fault handler will set the bit manually.

Thanks for your response. ;-) So the article is not against more common case, isn't it?

It's about the generic/theoretic case I guess, not the optimized implementation.

Quoted 2 lines

Quoted 2 lines

When mapped pages reach the end of the inactive list and have that bit set, they get activated, see page_check_references().

Quoted 2 lines

It seems that the page should trigger page fault twice and page_check_references can active it.

The first one brings it into memory (major fault), the second one sets the referenced bit (minor fault or set by mmu). Then it gets activated. That is the case for mmap accessed pages.

Buffered IO (read/write syscalls) enters the kernel anyway, so we activate the pages right then and there with mark_page_accessed().