Hi Matthew Wilcox: >On Wed, Oct 18, 2023 at 09:30:03AM +0800, Zhiguo Jiang wrote: >> If the dirty folio is not reclaimed in the shrink process, it do not >> need to unmap, which can save shrinking time during traversaling the >> dirty folio. > >Don't we have to unmap it first in order to make sure that all the dirty bits from the PTEs have been transferred to the folio dirty bit? Yes, if the PTE has the dirty bit, try_to_unmap will transfer it to the folio dirty bit. But the another condition is that the folio dirty bit has been already saved before try_to_unmap. For this situation and the PGDAT_DIRTY flag is not set, the dirty folio can skip unmap to save the shrink time. The patch submitted previously did not consider the dirty bit trasfferred by unmap, so the original part can be reserved. Please help to continue the review. Thanks -----邮件原件----- 发件人: Matthew Wilcox <willy@xxxxxxxxxxxxx> 发送时间: 2023年10月18日 22:12 收件人: 江志国 <justinjiang@xxxxxxxx> 抄送: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; opensource.kernel <opensource.kernel@xxxxxxxx> 主题: Re: [PATCH] mm: vmscan: the dirty folio unmap redundantly [Some people who received this message don't often get email from willy@xxxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Wed, Oct 18, 2023 at 09:30:03AM +0800, Zhiguo Jiang wrote: > If the dirty folio is not reclaimed in the shrink process, it do not > need to unmap, which can save shrinking time during traversaling the > dirty folio. Don't we have to unmap it first in order to make sure that all the dirty bits from the PTEs have been transferred to the folio dirty bit?
